[AlexTranAmz]

Fixes: N/A

What was the problem/requirement? (What/Why)

The openjd-sessions crate tags every record its session_log! macro emits with three log key-values: session_id, openjd_log_content (the LogContent bitmask) and openjd_timestamp_usec. The bindings install pyo3-log without its kv feature (rust-bindings/Cargo.toml), so those key-values are dropped before the Python LogRecord is built. Consumers of the openjd.sessions logger cannot tell which session a Rust-emitted record belongs to or what kind of content it carries. In the Deadline Cloud Worker Agent this means Rust session lines never reach the worker log, lines from concurrent sessions are not kept apart, and the job-attachments output-manifest lines are not picked up.

What was the solution? (How)

• rust-bindings/Cargo.toml: pyo3-log = { version = "0.13.1", features = ["kv"] }. The kv feature first shipped in pyo3-log 0.13.1 (Cargo.lock already resolves 0.13.4 and is unchanged). With it, pyo3-log passes each key-value as an extra attribute to Logger.makeRecord.
• rust-bindings/src/lib.rs: comment-only; the old comment described a logger-target remap that never existed (openjd-rs already logs to the openjd.sessions target).
• specs/python-sessions-interface.md: documents the three attributes. pyo3-log renders key-values as strings, so openjd_log_content and openjd_timestamp_usec arrive as decimal strings; the openjd.sessions._v1 wrapper (openjd-sessions-for-python) converts them back to LogContent and int. That companion change is a separate PR in that repository.

What is the impact of this change?

Records emitted by the Rust session runtime carry session_id (str), openjd_log_content (str of the bitmask) and openjd_timestamp_usec (str) as LogRecord attributes. Records that already carried nothing are unaffected. No Python API changes.

How was this change tested?

See DEVELOPMENT.md for information on running tests.

• Have you run the unit tests? Yes.

New test/openjd/sessions/test_logging.py runs one real openjd._openjd_rs.Session task in a child interpreter (pyo3-log caches each logger's level on first use, so the child sets openjd.sessions to INFO before importing the extension) and asserts that every record carrying openjd_log_content also carries session_id and openjd_timestamp_usec, that openjd_log_content is within the documented bit values, and that every session_id names the test's session. Against the unchanged build the test fails with "no record carried session_id".

Local results (Linux, this branch):

• hatch run test on Python 3.9, 3.10, 3.11, 3.12: 6331 passed, 26 skipped, 5 xfailed each; coverage 94.2-94.3% (gate 94%)
• hatch run lint, hatch run typing: clean on all four
• cargo build/clippy/test --all-targets --locked and cargo test --doc on rust-bindings: clean; cargo fmt --check clean
• Not run locally: Python 3.13/3.14, Windows, macOS (CI matrix). The test uses sys.executable -c so it does not depend on a shell.

Was this change documented?

• Are relevant docstrings in the code base updated? Yes: specs/python-sessions-interface.md logging section and the lib.rs comment.

Is this a breaking change?

No. Three new attributes appear on records that the Rust runtime emits; no existing attribute or signature changes.

Does this change impact security?

• Does the change need to be threat modeled? No. The attributes carry a session id, a content-classification bitmask and a timestamp, all already present in the Rust log call; no new data leaves the process.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[github-actions]

Claude review · advisory

Reviewed c07dfc0 (changes since 0e086d9): 0 new, 0 resolved.

Open: 0 blocking · 0 should-fix · 0 nit. ✅ Nothing blocking.

_{Fix or reply to each thread; the next revision's review re-checks open threads and resolves those it agrees are handled. Resolving a thread yourself also closes it. Later revisions review only what changed.}

[jericht]

We will need something similiar to aws-deadline/deadline-cloud-worker-agent#1130 to remove Python 3.9 from our actions before we can merge