fix: Forward the create-time step symbol table to openjd-sessions

[leongdl]

What changed

The CLI now forwards each step's create-time resolved symbol table to openjd-sessions, at all three entry points: Session.run_task, Session.enter_environment and Session.exit_environment. An exit is keyed to the table its enter used, so an onExit resolves in the same scope as its onEnter.

A step's template-scope let (RFC 0007 §3.6) is resolved once at job creation with PathFormat.POSIX, so a create-time value cannot depend on the host that created the job. openjd-model used to also merge those bindings into script.let, and sessions re-evaluated the merged list at session time in the host's format, re-rendering its PATH values. On Windows, startswith(path("/foo/bar"), "/foo") flips from true to false between the two evaluations. Worse, the seeded value and the re-evaluated one land in the same symbol table and the re-evaluation writes last, so it overwrote the correct value.

With the merge and the re-evaluation both gone upstream, resolved_symtab is the only channel those values have into a session. create_job_with_symbol_tables replaces create_job so the tables built during instantiation come back instead of being discarded; LocalSession carries them keyed by step name, and each action looks up the one it needs.

This follows the Deadline worker agent's public commit 08a5878b, "feat: forward the resolved symbol table to the v0 session", where it replaced extra_let_bindings outright. A convergent fix that adopts an existing upstream design, not a new one.

It also fixes a live break

The CLI was still passing extra_let_bindings, which sessions removed in 0.12.0. The CLI never followed, so against a current sessions build any step with a let raised TypeError: Session.enter_environment() got an unexpected keyword argument 'extra_let_bindings'.

Users saw that as Cannot exit unknown Environment. The failed enter left the environment unregistered in the session but already recorded in the CLI's own entered list, so the step's finally exit tripped over it and masked the real error.

extra_let_bindings is removed outright rather than kept beside the new channel.

Dependency floors

Both had to move; neither existing range contained a release with the needed API.

openjd-sessions goes to >= 0.12.0, < 0.13. 0.12.0 is the first release with resolved_symtab on all three methods, and the release that removed extra_let_bindings. No single version carries both channels, so the floor has to move rather than being feature-detected.

openjd-model goes to >= 0.11.4, < 0.12, the first release exporting create_job_with_symbol_tables and JobWithSymbolTables.

Migration

Removing the merge upstream is a breaking change for any consumer that calls resolve_syntax_sugar() and does not forward a resolved symbol table to its session. Such a consumer silently loses step-level bindings rather than failing. The worker agent forwards, and this PR is the CLI following. A third-party consumer would not, and there is no in-process fallback, because no Python Step carries the resolved table.

Verification

Suite went from 2 failed / 311 passed to 318 passed. The two prior failures were the extra_let_bindings break described above.

Conformance through this branch's CLI: 1172 passed, 2 failed. expr2.2.1--string-conversion and expr2.3.2--path-construction both pass — the two fixtures that pull in opposite directions, one wanting a value that has left path-space to stay /mnt/out and the other wanting a path to render in the host's format. The 2 failures are pre-existing range-normalization cases, unrelated to this change and blocked on a spec ruling.

Upstream suites: model 5496, sessions 999.

Not verified

Windows. The companion sessions PR, OpenJobDescription/openjd-sessions-for-python#362, has had its Windows CI legs fail-fast cancelled on every round, so Windows has never been exercised by CI there. The behaviour was proven by simulation instead: with the host format forced to Windows in-process, a path-typed binding renders \a\b while a value that has left path-space stays /mnt/out.

The conformance runner concatenates a fixture's output block with its output_<os> block, so on a POSIX host an output_windows block is never asserted. A green POSIX conformance run proves nothing about the Windows expectations.

---

Stack note. The first three commits (af52126, a328431, ae5bdaa) are preceding local work on the RFC 0007/0008 test and comment surface, carried on this branch. 1b90918 is the change described above.

[github-actions]

step_symbol_tables is optional with a None default, and every downstream lookup is self._step_symbol_tables.get(step.name). Combined with the invariant this PR documents extensively — that the resolved table is the only channel a step's template-scope let has into the session — that means any caller that omits it (or any step name missing from the mapping) gets a session where the step's let names are silently undefined rather than an error. The failure surfaces as an unresolved-symbol error from deep inside the session, or worse, as an action that runs with the wrong scope.

do_run is the only production caller and it always has the tables, so consider making the parameter required (keyword-only, no default) so the type checker catches an omission at the call site instead of at action-evaluation time. _run_local_session (_run_command.py:328) has the same Optional[...] = None default for the same reason.

[leongdl]

Nit, not taken. do_run is the only first-party caller and it always passes the full mapping returned by create_job_with_symbol_tables, so a required keyword-only parameter would buy type-checker coverage on a call site that is already correct while breaking any out-of-tree caller of _run_local_session. The degradation is documented at the assignment and the failure is loud rather than silent — an unresolved name surfaces as ActionState.FAILED with Undefined variable in the action log, not as a wrong-scope run.

[github-actions]

Both lookup sites (run_step here and run_task at line 391) use .get(step.name), so a step name absent from step_symbol_tables degrades to resolved_symtab=None silently. Per this PR's own documented invariant, that is not a benign degradation — the step's let names become undefined, and the error surfaces later as an unresolved-symbol failure inside the session action, pointing at the template rather than at the missing table.

Since create_job_with_symbol_tables is expected to return a table for every step of the job it built, a missing key means the mapping and the Job came from different creations (or a step name was transformed between them). Consider self._step_symbol_tables[step.name] — a KeyError at the boundary is far more diagnosable than a template-scope let quietly evaluating to nothing.

[leongdl]

Nit, not taken, for the same reason as the sibling thread. Switching to self._step_symbol_tables[step.name] would trade a documented None degradation that already fails loudly — ActionState.FAILED carrying Undefined variable — for a KeyError at the boundary, with no user-facing gain given the single first-party caller always supplies a table for every step of the job it built. Left as .get() with the invariant recorded at the assignment.

[seant-aws]

Independent edge-case testing — 14 templates, all pass

Checked out the PR locally, resolved openjd-sessions 0.12.0 + openjd-model 0.11.6, and ran the PR's own tests (5/5 pass) plus 14 additional templates targeting the untested surface of the _entered_env_symtabs dict-keying and symbol-table scoping:

Dict-keying (env_id has no step component):

• Duplicate step-env names in one step → model rejects ("Duplicate values for name are not allowed") — double-pop bug is schema-unreachable
• Two steps sharing a step-env name with different let values → AlphaExit=ALPHAVAL / BetaExit=BETAVAL, not crossed (each step fully exits before the next enters)
• Three distinct step envs → LIFO exit pairing correct, all resolve
• onExit after onEnter action fails (exit code 3) → ExitAfterFail=FAILVAL — retained key works as designed
• Pre-registration failure (RFC 0008 wrap conflict on a step env with let) → stale key created but provably inert (job aborts, cleanup never pops it)

Scoping:

• Cross-step let contamination → model rejects ("Variable avar does not exist... Did you mean: bvar")
• Step with no let but with a step env → table present anyway (Step.Name resolves) — confirmed create_job_with_symbol_tables populates a table for every step unconditionally
• Chained bindings (a=2, b=a*5) → Chained=10
• 3-task parameter space → all tasks see the let value
• PATH-typed binding (path("/foo/bar"), startswith) → resolves correctly on Linux
• let shadowing a job parameter → structurally impossible (capitalized names are reserved namespaces)
• Step named My Step-Name → works, including --step selection

No bugs found. The forwarding chain is correct end-to-end. The .get() / optional decisions are defensible — degradation is loud (ActionState.FAILED / Undefined variable), and the table is always present for any real step. LGTM.