chore(release): 0.33.1

[client-software-ci]

0.33.1 (2026-08-26)

Features

• The resolved symbol table is now forwarded to v0 sessions, enabling downstream session actions to access resolved symbols. (feat: forward the resolved symbol table to the v0 session #1077)

Bug Fixes

• Fixed incorrect host CPU and disk utilization metrics. CPU and disk usage values are now reported correctly. Additionally, host metrics collection is now non-fatal — if the metrics thread cannot be started, the agent will log a warning instead of crashing. (fix: sample host CPU utilization on a long-lived metrics thread #1036)

[github-actions]

The disk part of this entry does not match what #1036 actually landed, and it collides with a change that already shipped.

#1036 (0e53040) only touches src/deadline_worker_agent/metrics.py and test/unit/test_metrics.py. Its metrics.py changes are: Timer → long-lived Thread, _prime_metrics(), the nvidia-smi timeout=/TimeoutExpired handling, and the non-fatal thread start. There is no change to any disk usage computation — total-disk-used-percent is untouched by that commit.

Worse, the commit explicitly split the disk-percentage fix out into its own change ("refactor: move the total-disk-used-percent fix to its own change ... it rescales a published metric by 100x, so it needs its own BREAKING CHANGE entry"). That fix is #1067, and it is already released above under 0.33.0 as a BREAKING CHANGE. So "disk usage values are now reported correctly" re-announces an already-shipped change, and announces it as a non-breaking bug fix this time — the opposite of what that split was for. A reader upgrading 0.33.0 → 0.33.1 will reasonably expect another disk-metric rescale in this release.

The disk-rate metrics are not really fixed here either: before this change __enter__ called log_metrics() immediately, which set _prev_disk_counters, so the read/write byte-rate baselines were already primed. _prime_metrics() preserves that behavior on the new thread rather than correcting it.

The CPU claim is accurate and is the substantive fix (each Timer ran on a fresh thread, so psutil.cpu_percent() was always that thread's first call and returned psutil's uninitialized value). Suggest dropping the disk claim:

• Fixed host CPU utilization being reported as zero. Metrics are now sampled from a single long-lived thread so CPU percentages reflect the sampling interval. Additionally, host metrics collection is now non-fatal — if the metrics thread cannot be started, the agent will log a warning instead of crashing. (fix: sample host CPU utilization on a long-lived metrics thread #1036)

[github-actions]

#1077 also bumped a hard-pinned runtime dependency, and that is not mentioned in these release notes.

08a5878 changes pyproject.toml:

-    "openjd-sessions == 0.11.0",
+    "openjd-sessions == 0.12.0",

The pin is exact (==), and per that PR's own comment the coupling is bidirectional: resolved_symtab was added to the v0 Session's enter_environment/exit_environment/run_task (so these calls TypeError against 0.11.0), and extra_let_bindings was removed from the same three methods (so anything still passing it TypeErrors against 0.12.0).

That matters to two audiences the changelog serves:

1. Anyone installing the agent into a shared environment — an exact pin moving from 0.11.0 to 0.12.0 can hard-conflict with other packages pinning openjd-sessions, and gives no way to resolve it other than not upgrading.
2. 0.33.0 above already documents a session_runtime config and a Rust runtime adapter, so consumers are actively tracking which OpenJD versions each agent release requires.

The wording is also thin for the audience: "the resolved symbol table is now forwarded to v0 sessions, enabling downstream session actions to access resolved symbols" restates the mechanism rather than the effect. 0.33.0's entry for the sibling change (#1063) shows the useful shape — it names the concrete symbols (Job.Name, Param.*, RawParam.*, step let values). This entry is the v0/Python-runtime counterpart of that, which is worth saying, since a reader who applied #1063 has no way to tell from this text that it previously only covered the Rust runtime.

Suggested:

• The resolved symbol table is now forwarded to v0 (Python runtime) sessions, so pre-resolved EXPR symbols (Job.Name, Param.*, RawParam.*, step let values) are available to environment and task actions there, matching the Rust runtime support added in 0.33.0. Requires openjd-sessions == 0.12.0. (feat: forward the resolved symbol table to the v0 session #1077)