[bosprimigenious]

Description

Fixes #6157. After a promotion fails, run can keep warning that the environment "is being updated" even though the plan process has exited. The readiness check observes persisted finalization state; it does not detect a running process.

This change identifies the unfinalized state, explains that the plan may still be running or may have failed, and includes the configured retry interval/maximum wait. The timeout points to plan logs, resolving the failure, and successfully reapplying sqlmesh plan <environment>. The Run configuration documentation explains the same distinction.

- Environment 'prod' is being updated by plan '...'. Retrying ...
+ Environment 'prod' is not finalized after plan '...'.
+ The plan may still be running or may have failed.
+ Waiting for environment finalization, retrying ... (configured maximum wait: ...).

Only diagnostic strings change in context.py: the finalization guard, state records, retry loop and sleep/timeout calculations remain unchanged. There is no state-clearing workaround or active-process detection.

Draft / NOT READY. Full make style exits 2: mypy reports 125 errors in 67 files, matching the pristine baseline after normalizing line shifts (500 source files checked). Full fast-test collection exits 2 with 23 optional dependency import errors; it has not executed successfully. The four pre-existing tests in the affected integration module also fail during missing BigQuery SDK fixture setup, on both baseline and patched source. Other engine/Python/OS matrices remain unverified.

Test Plan

• Test-first real DuckDB regression: the original diagnostics fail the new assertion after the guard, unchanged stored state, timeout, successful reapplication, and scheduler recovery assertions have passed. Patched: 1 passed, with 108 existing Pydantic deprecation warnings.
• The primary agent independently reran that regression and a fresh actual CLI sequence on both pristine and patched source: initial plan/run succeeds; deliberate virtual-promotion conversion failure exits 1; subsequent run times out after the configured 20 seconds; correcting the model and reapplying the plan restores a successful run. The patched timeout took 20.95 seconds. Python socket interception recorded 0 connection attempts in all six commands in each run.
• Independent AI code-reviewer reran the actual DuckDB guard regression and CLI failure path; no source/test/documentation changes were requested. AST comparison verifies behavior outside the diagnostic arguments is unchanged. A separate AI technical-writer checked the documentation against source/configuration defaults.
• Whole-repository Ruff check/format pass (504 Python files). Changed-file mypy passes. The normal signed commit ran all four installed hooks: Ruff, Ruff format, mypy, valid migrations; all pass. These scoped checks do not override the full-check failures above.
• A normal local wheel build generated the ignored SCM version module and succeeded without installing/publishing the wheel, changing tracked dependency files, or altering the original runtime package versions. This removed local metadata-only type failures; the remaining full type errors still match baseline.
• No Trino/PostgreSQL, live warehouse, Docker or full slow-test validation is claimed. No provider/network mocks were added to substitute for those checks.

Checklist

• I have run make style and fixed any issues (run; baseline full mypy errors remain)
• I have added tests for my changes (real failed-promotion, guard, timeout and recovery regression)
• All existing tests pass (make fast-test) (full collection blocked by optional dependencies)
• My commits are signed off (git commit -s) per the DCO

AI disclosure: generated and implemented with OpenAI Codex, including separate AI developer, technical-writer and code-reviewer roles. The primary agent independently repeated the key checks. This is agent-only verification; no human review is claimed.

Merge consideration: the waiting safety behavior is preserved in both directions: an unfinalized environment still blocks scheduling, and a successfully finalized/recovered environment still runs. This PR improves the diagnostics; it does not repair a failed plan automatically.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Tip

🎯 Customize your risk assessments

Guide how CodeRabbit assesses merge risk and security architecture risk. Highlight sensitive changes and explain your security boundaries using Merge Risk Instructions and Security Risk Instructions in your review settings. Security architecture risk assessments require the Advanced plan or above.

✅ Automatic approvals, with your rules

Let CodeRabbit approve pull requests once required threads are resolved, pre-merge checks pass, and your risk limits are met. Enable Automatic approvals in review settings, with overrides for teams or file paths.

CodeRabbit Verify

• Run CodeRabbit Verify to test the changes in this pull request.