Skip to content

chore(release): 0.33.0 #1069

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
seant-aws merged 1 commit into from
Aug 20, 2026
Merged

chore(release): 0.33.0 #1069

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
16 changes: 16 additions & 0 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,3 +1,19 @@
## 0.33.0 (2026-08-20)

### BREAKING CHANGES
* The `total-disk-used-percent` metric now reports on a 0-100 scale instead of the incorrect 0.0-1.0 fraction. Previously, a 25% full disk was reported as 0.25; it is now correctly reported as 25. If you have alerts or dashboards based on this metric, update your thresholds accordingly. (#1067)

@github-actions github-actions Bot Aug 20, 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 "previously reported as 0.25" example is not what the old code actually emitted.

The pre-fix expression was round(disk.used / disk.total, ndigits=1) — rounding to one decimal place. So a 25%-full disk was emitted as 0.2, not 0.25. The commit message for #1067 states this correctly ("A 25% full disk was reported as 0.2") and the old unit test asserted == "0.2", so this looks like a transcription slip when the note was written.

This matters more than a typo here, because the whole point of the entry is to help operators re-tune alarms: someone reconstructing their old thresholds from 0.25 will assume the old series had two-digit precision, when in reality every value was quantized to 0.1 (i.e. only 11 distinct values ever appeared). Suggest:

Previously, a 25% full disk was reported as 0.2 (the fraction was also rounded to one decimal place, so the old metric only ever emitted values in 0.1 steps); it is now correctly reported as 25.0.

* Session working directory naming on Windows has changed (session ID prefix removed, `embedded_files` renamed to `ef`) for MAX_PATH compliance. This may affect workflows that depend on specific working directory paths. (#1068)

@github-actions github-actions Bot Aug 20, 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 dependency changes behind this release are not recorded, which breaks a pattern the previous release established.

0.33.0 changes two requirements in pyproject.toml:

openjd-sessions is an exact pin (the comment above it explains why: "Host Config Script runner usage of private OpenJD Sessions API"). An exact-pin bump is the kind of thing that breaks pip install for anyone resolving this agent alongside another package that pins openjd-sessions differently, and there is no way to discover it from these notes.

0.32.0 documented exactly this kind of change as its own bullet — "Raised the openjd-model dependency floor to >= 0.11.3, which fixes: ..." (#1054) — so the omission here reads as an oversight rather than a deliberate style choice.

Related: this entry describes the consequence of the openjd-sessions bump (Windows working-directory naming) without saying a dependency moved at all, which leaves the breaking change looking like a worker-agent code change. Suggest naming the bump in the entry, or adding a separate dependency bullet covering both.


### Features
* Added support for EXPR parameter types (`bool`, `rangeExpr`, `stringList`, `pathList`, `intList`, `floatList`, `boolList`, `intListList`) in API response parsing. Jobs using these parameter types will no longer crash the session. (#1064)
* The worker agent now accepts and forwards the `resolvedSymbolTable` from the service to the session runtime, enabling pre-resolved EXPR symbols (Job.Name, Param.*, RawParam.*, step let values) to be used in sessions. (#1063)

@github-actions github-actions Bot Aug 20, 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.

"forwards the resolvedSymbolTable ... to the session runtime, enabling ... (Job.Name, Param., RawParam., step let values)" is true of the Rust runtime only. On the default Python runtime the list is much narrower.

Per #1063, the Python adapter "accepts and ignores" the table for symbol resolution (v0 resolves EXPR natively); the only thing it pulls out is Job.Name, which it passes as job_name= to the classic openjd Session constructor. Full forwarding to enter_environment / run_task / exit_environment via resolved_symtab= is the Rust path.

Since session_runtime defaults to python, the runtime most readers are on gets one of the four symbol categories listed. As written the entry promises Param.*, RawParam.*, and step let resolution to everyone.

Suggest splitting the claim: "...On the Rust session runtime the table is forwarded to the session, enabling pre-resolved EXPR symbols (Job.Name, Param., RawParam., step let values). On the Python session runtime, Job.Name is seeded from the table; the remaining symbols continue to be resolved natively."

* Session extension enablement is now driven by the job's declaration in `JobDetails`. Jobs can explicitly declare which extensions they need, and the worker agent will enable only those extensions (plus `REDACTED_ENV_VARS`). (#1062)

@github-actions github-actions Bot Aug 20, 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.

This is filed under Features, but as described it is the one entry in this release whose behavior can regress a working job without any change on the operator's side — it deserves a caveat here even if the classification stays.

Before #1062, Session.__init__ passed supported_extensions=RUNTIME_CAPABILITY_EXTENSIONS — every extension the worker implements, unconditionally. After it, the value is session_extensions(self._job_details.extensions), which returns tuple(set(job_extensions) | {"REDACTED_ENV_VARS"}) whenever the service populates the field. So the enabled set is now whatever the service sends.

Per the comment on RUNTIME_CAPABILITY_EXTENSIONS in sessions/_extensions.py, this list is a runtime switch, not just validation: "Omitting an extension from the session-level list disables the runtime feature." That means if the service ships an extensions value that is empty or incomplete for a job that genuinely uses, say, WRAP_ACTIONS, the worker will now disable it — and the failure mode is a template feature quietly not taking effect, not a clean validation error. The None-means-all fallback covers the pre-deployment case, but not a service that populates the field with a set narrower than the job actually needs.

Two suggestions:

  1. Note the fallback explicitly so operators can reason about it: "...When the service does not send the field, all extensions the worker implements remain enabled, as before."
  2. Say what happens on mismatch, since that is the actionable part for anyone debugging a job whose extension stopped working after upgrading to 0.33.0.


### Bug Fixes
* Fixed step-scoped environments not receiving their step's name and let bindings, which could cause incorrect environment configuration during sessions. (#1061)
* Fixed a crash when jobs use LIST parameter types (e.g., `LIST[STRING]`, `LIST[INT]`) due to incorrect Rust parameter type enum member lookup by value instead of name. (#1066)

@github-actions github-actions Bot Aug 20, 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.

This entry omits the two facts a reader needs to decide whether it affects them.

  1. It is Rust-runtime-only. The bug was in _to_rust_parameter_values() in sessions/runtime/rust.py; fix: resolve Rust parameter type enum members by name, not value #1066's own commit message says "The Python runtime is unaffected." As written, the entry reads as a general "jobs using LIST parameters crash," which will worry the majority of users who are still on the default Python runtime (session_runtime defaults to python) and were never exposed.

  2. CHUNK[INT] task parameters were also affected. The root cause was getattr(type_cls, value.type.value) failing for any enum value that isn't a valid attribute name — that is all six LIST[*] job parameter types and CHUNK[INT] task parameters. Someone hitting the CHUNK[INT] failure will not find it in these notes and may reasonably conclude their bug is still open.

Suggest: "Fixed a crash under the Rust session runtime when jobs use LIST[*] parameter types (e.g. LIST[STRING], LIST[INT]) or CHUNK[INT] task parameters, caused by resolving the Rust parameter type enum member by value instead of by name. The Python session runtime was not affected."

* Fixed EXPR parameter types being rejected during job entity validation, which prevented jobs using these parameter types from running via the BatchGetJobEntity path. (#1065)
* Fixed materialized embedded files on Windows not having correct permissions. An explicit Windows ACL is now set granting the agent user full control and the job user read access, preventing issues when NTFS inheritance is absent or misconfigured. (#1059)

@github-actions github-actions Bot Aug 20, 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.

"granting the agent user full control" overstates the ACL that is actually set.

The code in #1059 passes agent_user_permission=FileSystemPermissionEnum.READ_WRITE, not FULL_CONTROL. Those are distinct members of FileSystemPermissionEnum, and they map to different Windows access masks in file_system_operations.py:

  • READ_WRITE → FILE_GENERIC_READ | FILE_GENERIC_WRITE | FILE_DELETE_CHILD
  • FULL_CONTROL → ntsecuritycon.GENERIC_ALL

So the agent gets read/write, not full control (no WRITE_DAC/WRITE_OWNER). Since this entry is the customer-facing description of a permissions change, describing a narrower grant as the broadest one is the wrong direction to be imprecise in — an operator auditing ACLs against this note would expect GENERIC_ALL and find something else.

Also, the entry says "materialized embedded files on Windows," which reads as covering all embedded-file materialization. The change is scoped to the Rust session runtime adapter's stopgap materialization path (sessions/runtime/rust.py); the Python runtime path is untouched. Worth scoping the sentence so Python-runtime users don't read this as a fix that applies to them.

Suggest: "...An explicit Windows ACL is now set granting the agent user read/write and the job user read access on files materialized by the Rust session runtime..."

## 0.32.0 (2026-08-14)

### BREAKING CHANGES
Expand Down
Loading