Repository navigation
Expose acknowledged activity heartbeat checkpoints - #333
Conversation
rmcdaniel
left a comment
There was a problem hiding this comment.
Rust peer API/source review: PASS for exact 2fd389c058822705507077b137ea8f0ca4c8189e, scoped to the Python acknowledged-checkpoint accessor. I read the complete ten-file delta and the surrounding poll/ActivityInfo/handler path; the retained ten source blobs match their Git identities.
The actual client poll captures only an explicit supported v1 delivery. Common canonical identity, positive integer attempt, namespace/owner and the requested queue when present are checked before the empty/populated branch. Supported null/null therefore remains distinct from unavailable, and a populated checkpoint requires a later attempt. The handler rechecks captured claim identity before exposing the snapshot; a legacy/copied plain task dictionary cannot invent participating empty state. The public wire dictionary and existing retry/deadline/writer paths are preserved.
The frozen checkpoint stores an independent JSON snapshot, returns new detail copies through the existing typed-value decoder, hides details from repr and survives supervised callback serialization. The acknowledgement API explicitly returns the original RFC3339 string, preserving its fractional digits without a lossy Python datetime conversion. Contract version 1 is correctly distinguished from an absent write sequence. Successful, refused and uncertain heartbeat outcomes do not mutate the received snapshot. The source controls cover those outcomes and the populated/empty identity boundary; documentation marks the API unreleased and retains external-effect reconciliation/fencing caveats.
No blocking source finding. I executed no SDK tests, compiler, Worker or Server for this review. Current CI, Security review, publication and the actual named published-package replacement/batch evidence remain separate gates; this does not close shared #218 or establish mode parity.
|
Current source is |
|
rmcdaniel
left a comment
There was a problem hiding this comment.
Scoped successor source rebind: PASS for exact 97b07b0458ece801d199f774738ee49a29215620.
I reviewed the complete two-file delta from my full 2fd389c review. The new capability moves into the existing base capability tuple consumed by registration, and four expected list orders move with it. There is one advertisement, with the same name and behavior; the parser, immutable snapshot/accessors, actual poll capture and handler identity checks are unchanged. No corpus fixture or policy is weakened. The registration method returns to the accepted baseline bytes while the base tuple explicitly advertises the additive capability.
No new blocking finding. This rebind carries only my source/API review; I ran no tests or SDK/Server entrypoint and make no package, installed replacement or parity claim. Fresh exact-head CI and required Security/publication/installed gates remain with the owner.
|
SECURITY SOURCE PASS on exact I reviewed the poll boundary, claim-to-handler binding, public accessors, supervised-callback serialization and the final registration-tuple correction. The implementation is fail-closed at the intended seams:
The focused checkpoint/registration controls and supported-version lanes are green on this exact head. Normal current-head integration/quality still gate merge. This verdict is source/API only: it is not package publication, installed cold-replacement evidence, a Server producer verdict, or runtime acceptance for shared #218. |
|
The Python checkpoint accessor is merged normally at This delivers source/API preparation only. The public stable portal remains on the separately selected published SDK2.17.2 guide, and no new package, installed checkpoint observation or shared218 parity claim is made. The bounded batch example and published-package replacement qualification remain unfinished acceptance work. |
|
Security source/API review PASS at exact The v1 boundary is closed as requested:
The final two-file registration correction keeps |



Python activities can write heartbeat details but cannot read the acknowledged checkpoint received with a replacement claim. This adds read-only
ActivityContextcheckpoint/details/time accessors and an immutableActivityHeartbeatCheckpoint, with optional decoding through the existing typed-value converter.The worker advertises
activity_heartbeat_resume; only an explicit v1 poll delivery with matching execution, attempt, workflow, run, namespace and owner can supply the snapshot. Unsupported or omitted deliveries raiseActivityHeartbeatResumeUnavailable, while a supported null/null pair returnsNone. The task's wire dictionary stays unchanged. Claim mutation and malformed metadata refuse before the handler, and successful, refused or uncertain heartbeats never advance the received snapshot. The raw RFC3339 time retains fractional precision; v1 is a contract version, not a checkpoint write sequence.Validation: 63 new checkpoint controls pass, including real-client mock transport, typed values, identity refusal, heartbeat outcomes and supervised callback serialization. The broader activity/worker suite passed 417 tests with two existing skips before the final timestamp-only controls; Ruff, mypy and diff checks pass. Normal supported-version CI follows.
Implements the Python source/API portion of durable-workflow/.github#218. Package publication, actual published-package cold replacement and the bounded batch example remain required before its Python acceptance is complete. The reference labels this API unreleased.