Repository navigation
Empty callback exception messages prevent activity failure reporting #222
Description
A callback exception with an empty message cannot be reported as a failed activity. For example, raise AssertionError() reaches the worker's error handler, which sends failure.message: ""; Server rejects it with 422 / The failure.message field is required. The worker logs that reporting failed, and a standalone activity remained running through the caller's 30-second result deadline.
Reproduced during Python 2.12.0 unpublished candidate qualification at 105e174a6cc5ef855f006fff36afc5526c4862e8 against published Server 2.11.4 (sha256:9dd7e5fc8382c0bbdda106ffac86ab8edc4264545e2df3c7e43209884fb8091d). The same message=str(e) activity-failure reporting path is present in published 2.11.2 source 43be84a9e081141db9ec4af0eca4cdc245dd6efb; a separate published-2.11.2 runtime reproduction is not claimed.
Use a useful non-empty fallback for blank exception messages, preserving the actual failure type, original attempt/lease identity, stack and bounded failure-report contract. Cover ordinary and supervised callbacks, whitespace-only messages and a real connected activity: one failed completion must be accepted and the caller must receive a terminal typed failure rather than an unexplained timeout. Check the corresponding local/workflow failure paths for the same report-shape problem.
This is a separate pre-existing failure-reporting defect, not a regression or a new gate on the original-context capability in #221 / shared250. #167 addressed empty transport diagnostics and #100 accepted update failures; neither owns this worker-to-Server empty callback failure.
Activity
rmcdaniel commentedon Oct 27, 2026
General accepted triage and implementation after the active Server bridge/admission slice. Preserve failure type, attempt/lease identity and reporting bounds; cover ordinary/supervised blank and whitespace-only exceptions plus a connected terminal-failure result. This remains separate from the delivered 2.12.0 activity-context feature.
rmcdaniel commentedon Oct 27, 2026
General implemented the repair at
1b4c66bonfix/222-empty-callback-failure.A shared exception-message helper preserves nonblank diagnostic text exactly and uses the original exception type when the message is empty or whitespace-only. Ordinary and supervised activity callbacks, invocable handlers, workflow/update failures and query refusals use it. Local activity reporting already has a nonblank fallback. Failure type/class, stack, retry classification and the original task/attempt/lease authority remain unchanged; existing report bounds still apply.
Qualification on Python 3.12:
sha256:9dd7e5fc8382c0bbdda106ffac86ab8edc4264545e2df3c7e43209884fb8091d, local amd64 configsha256:d925129892b0bc89e7c2f01c57a100afc217d46ee42b68ae3ffefc86bb71d89d: four cases passed (ordinary/supervised × empty/whitespace). Each submits one accepted HTTP 200 failure completion, preserves attempt/lease fields and stack/type, and the caller receives terminalWorkflowFailedinstead of timeout.failure.messagerequired; the activity remains running until the 15-second result timeout. The focused old-code controls fail 13 cases and pass eight nonblank/existing-fallback controls.This is source-candidate evidence, not a published SDK patch or installed-package completion. Normal PR/release and fresh PyPI-installed acceptance remain. The runtime fixture containers/network/database will be removed after retaining this receipt; the source worktree and isolated test environment remain for delivery.
rmcdaniel commentedon Oct 27, 2026
Additional qualification at source
5525976: the existing replay-corpus policy correctly required durable evidence for the workflow failure-message change. Addedblank-workflow-failure-message.jsonand its real replay workflow. All 66 replay corpus tests pass; the same case fails on unchanged baseline source because it emits whitespace instead ofAssertionError. The normal corpus guard passes with nine source/test paths, replay fixtures69→70 and codec fixtures unchanged42. Full Ruff still passes. The earlier full-unit, strict-mypy and four real connected results remain valid for the unchanged application source. Runtime containers/network/database were removed after evidence.Next: normal PR/patch publication and fresh installed-PyPI acceptance. The source receipt does not claim a published fix.
rmcdaniel commentedon Nov 2, 2026
Source follow-through now lives in draft #226 at
baf3845, handed over by General. It carries 1b4c66b and 5525976 onto current main; the only conflict was the replay corpus workflow list. It also routes the remaining query and update-validator rejection paths through the same helper, becausestr(exc) or fallbacklet whitespace-only messages through. On this head: unit 3,674 passed, with 2 environment-only boundary-scanner failures (macOS bash 3.2); ruff and mypy pass; the corpus guard passes; the blank-failure corpus counterfactual still fails on the main base. Connected/container qualification hasn't been run on this head yet.Fix blank failure reports and prepare Python SDK 2.12.3 (#226)
rmcdaniel commentedon Nov 2, 2026
Independent Security provenance verification for published Python SDK 2.12.3 is complete; no finding.
fe3a65e5ff15e2f420e162979c8bac5d6a6fb5cbnames2.12.3and points to protected squash mergec67353cad41eb0323819fc2a4b362b331c821889. The merge treeb2ed5444dbd24684a286f76aa8c3b41acb1212d5is byte-identical to accepted PR headbfd48bd7213dbb7ef893886a0d386b3b099b48a4.13152869822, SHA-256a2c4bb2d3da54781185b006bc71652cdbf894baabf9db8c8388e11814120aba6, from the same run/attempt before extraction and OIDC publication.f509643cce6bff4be695d70bc8e6315b7dbd9a0a454ff5d83dd4c43a1c3f7f03; the sdist is 629,181 bytes, SHA-256f8b4c3c13ea2b800b4dc49881023bfd8cddccb9e3a2cf61e3c0b58a0df25f76a. Both are byte-identical to GitHub build artifactdistfrom the publisher run.durable-workflow/sdk-python, workflowpublish.yml, environmentpypi. Each in-toto subject name and SHA-256 matches the downloaded file and PyPI JSON exactly.pyproject.toml, README and license match. Wheel and sdist metadata agree on name/version, Python floor, dependencies and project URLs.The annotated Git tag itself is unsigned; this release provenance is therefore the exact-source protected-main/publisher-handoff/PyPI trusted-publisher and attestation chain, not a signed-tag claim. That matches the current release design and is not a new hold. General remains responsible for fresh registry-installed behavior against the published Server artifacts. No PHP Server release is involved.