`--execution-time` flag is ignored in `sqlmesh plan` only in prod (not in dev)

[michiel-de-muynck]

Actual behavior:

Given a model

MODEL (
    name sqlmesh_example.demo,
    kind INCREMENTAL_BY_TIME_RANGE (
        time_column day,
        batch_size 1
    ),
    start '2025-12-20'
); 
SELECT @start_ds AS day;

When running sqlmesh plan --execution-time '2025-12-26', the intervals between the model's start date and the execution time are filled (in this case 2025-12-20 until 2025-12-25) are created as expected.

However, subsequently running sqlmesh plan --execution-time '2025-12-28', sqlmesh does nothing, just stating:

No changes to plan: project files match the prod environment

This happens only in prod. If I do the same in dev environments, then the intervals 2025-12-26 and 2025-12-27 are filled as expected.

Expected behavior:

Since I explicitly pass --execution-time '2025-12-28', I expect the intervals 2025-12-26 and 2025-12-27 to be filled.

If this is somehow intended behavior, then at least I expect:

• dev and prod to behave the same way
• the documentation should mention this gotcha

Self-contained reproduction script:

# create temp dir for sqlmesh project
cd $(mktemp -d)
python -m venv .venv
source .venv/bin/activate
pip install sqlmesh

# create empty sqlmesh project with all defaults (duckdb)
yes 1 | sqlmesh init -t EMPTY

# create model
echo "\
MODEL (
    name sqlmesh_example.demo,
    kind INCREMENTAL_BY_TIME_RANGE (
        time_column day,
        batch_size 1
    ),
    start '2025-12-20'
); 
SELECT @start_ds AS day;
" > models/demo.sql

echo "Running in dev with --execution-time '2025-12-22'"
sqlmesh plan dev --execution-time '2025-12-22' --auto-apply

echo "Looking at the data:"
sqlmesh fetchdf "select * from sqlmesh_example__dev.demo"
# Note: this prints (as expected):
#           day
# 0  2025-12-20
# 1  2025-12-21

echo "Running in dev with --execution-time '2025-12-24'"
sqlmesh plan dev --execution-time '2025-12-24' --auto-apply

echo "Looking at the data:"
sqlmesh fetchdf "select * from sqlmesh_example__dev.demo"
# Note: this prints (as expected):
#           day
# 0  2025-12-20
# 1  2025-12-21
# 0  2025-12-22
# 1  2025-12-23

echo "Running in prod with --execution-time '2025-12-26'"
sqlmesh plan --execution-time '2025-12-26' --auto-apply

echo "Looking at the data:"
sqlmesh fetchdf "select * from sqlmesh_example.demo"
# Note: this prints (as expected):
#           day
# 0  2025-12-20
# 1  2025-12-21
# 0  2025-12-22
# 1  2025-12-23
# 0  2025-12-24
# 1  2025-12-25

echo "Running in prod with --execution-time '2025-12-28'. Should update the model (but doesn't)!"
sqlmesh plan --execution-time '2025-12-28' --auto-apply

echo "Note that the above incorrectly prints:"
echo "  No changes to plan: project files match the prod environment"
echo ""
echo "Notice the model still shows the only the days 20 to 25:"

sqlmesh fetchdf "select * from sqlmesh_example.demo"

[rar-file]

I dug into this a bit (sqlmesh 0.235.3, reproduced with the script from the description).

The snapshot-level interval math is fine — calling Snapshot.missing_intervals("2025-12-20", "2025-12-28", execution_time="2025-12-28") on the prod snapshot returns the missing 26th/27th intervals. What suppresses them is the plan-level end cap: when no --end is given, Context.plan_builder() sets default_end to the max interval end already loaded in prod (_get_plan_default_start_end, with the comment "to prevent unintended evaluation of the entire DAG"), and additionally passes end_override_per_model=max_interval_end_per_model, which caps each model's missing-interval scan at its existing frontier. The clamp between default_end and execution_time only works downward (default_end is reduced if it exceeds an explicit --execution-time), never extended up to it — so an --execution-time past the prod frontier is effectively ignored.

Two observations that might help triage:

• The dev/prod asymmetry is a red herring: dev only "works" in the repro script because the dev plans run before prod exists, so there's no prod frontier to cap to. Once prod exists, a no-change dev plan errors out with "Creating a new environment requires a change", so dev and prod are actually consistent.
• sqlmesh plan --run --execution-time '2025-12-28' --auto-apply fills the missing intervals correctly (run=True skips both caps). Plain sqlmesh run doesn't accept --execution-time at all, so today the --run flag is the only way to do this.

So the open question is what the intended behavior should be: extend the plan end to an explicitly passed --execution-time, warn and point at --run/--end when --execution-time exceeds the prod frontier, or document the gotcha (and maybe add --execution-time to sqlmesh run). Happy to put together a PR once a direction is picked.

[nnqtruong]

Thanks @rar-file — your triage matches what I found in the code, and I'd like to move this forward. I went with extending the plan end to an explicitly passed --execution-time, because the codebase already treats explicit user time bounds that way: an explicit --end drops the per-model interval-end caps entirely (PlanBuilder.override_end), and plan --run --execution-time X (no caps at all) already handles this scenario correctly — so raising the caps up to an explicit execution time can't schedule anything --run wouldn't. Default behavior (no --execution-time, or an explicit --end, or a first deploy) is untouched, and the downward clamp (prod intervals newer than the execution time) still applies.

I have the fix + tests ready on nnqtruong:fix-5640-plan-execution-time, including a test asserting plan --execution-time X reports exactly the missing intervals plan --run --execution-time X would. Opening a PR shortly — happy to adjust if maintainers prefer the warn-and-point-at---run direction instead.