Skip to content

chore(release): 0.33.1 #1079

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
leongdl merged 1 commit into from
Aug 26, 2026
Merged

chore(release): 0.33.1 #1079

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,3 +1,10 @@
## 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. (#1077)

@github-actions github-actions Bot Aug 26, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#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)


### 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. (#1036)

@github-actions github-actions Bot Aug 26, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

## 0.33.0 (2026-08-21)

### BREAKING CHANGES
Expand Down
Loading