The run's bare names, and one clock behind them (#104) - #459
Merged
Conversation
`{{ pipeline_id }}`, `{{ execution_id }}` and `{{ timestamp }}` are
registered by the runtime and render correctly. All three were reported as
undefined variables -- the same false positive `execution.timestamp` had
before #454 declared it, just without the prefix.
Declaring them turned up the interesting part. `{{ timestamp }}` and
`{{ execution.timestamp }}` name one thing and disagreed:
bare: 2026-08-03T08:07:56.022350
exec: 2026-08-03T12:07:56.022379+00:00
Four hours and 29 microseconds apart, in one run. `TemplateManager`
seeds a base context from `datetime.now()` when the *manager* is
constructed -- neither the run's start nor the same value, and in local time
without a zone while the run context is UTC. #454 consolidated the seven
`execution` dicts and missed this one, because it hides under a different
name.
The run now registers the bare alias from the same namespace, so both
spellings are the same instant. `runtime/execution_state.py` had a third
reading of its own; it takes the run's answer too.
`current_timestamp` and `current_date` appear in the catalogue about as often
as the real names and are populated by nothing. They stay refused, and a test
says so -- declaring three names must not wave through every bare name.
Measured: catalogue validating 48 -> 50 of 117; blocking suite 725 -> 731
passed, 0 failed.
Three mutations, all killed:
- stop overriding the constructed timestamp -> the agreement test
- data-flow validator forgets the names -> 3 tests
- declare names the runtime does not give -> 4 tests
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
{{ pipeline_id }},{{ execution_id }}and{{ timestamp }}are registered by the runtime and render correctly. All three were reported as undefined variables — the same false positiveexecution.timestamphad before #454 declared it, just without the prefix.Declaring them turned up the interesting part
{{ timestamp }}and{{ execution.timestamp }}name one thing, and disagreed:Four hours and 29 microseconds apart, in one run.
TemplateManager._setup_base_contextseedstimestampfromdatetime.now()when the manager is constructed — neither the run's start nor the same value, and in local time without a zone while the run context is UTC.#454 consolidated seven
executiondicts and missed this one because it hides under a different name.runtime/execution_state.pyhad a third reading of its own. Both now take the run's answer:Not every bare name
current_timestampandcurrent_dateappear in the catalogue about as often as the real ones and are populated by nothing. They stay refused, and a test says so — declaring three names must not wave through every bare name.pipeline_idexecution_idtimestampcurrent_timestampcurrent_dateMeasured
Started this line of work at 9/117.
Mutations — three, all killed
One process note:
git checkout <file>reverted uncommitted work mid-mutation-run, so the last "restored" check was against a broken tree. Caught it, restored, and re-ran both the focused suite and the full blocking suite from scratch rather than trusting the earlier numbers.🤖 Generated with Claude Code