[Feature]: Record execution exceptions on Workflow and Invocation spans
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- python
- Ambito
- observability
Direzione di ricerca
Start with the FAILED finalization branches in execution_plugin.py and invocation_plugin.py, then read the existing error-object event helper and coordinate the shared behavior through the RFC and linked conformance requirement. Add focused tests for both views and the specified failure and retry cases; done means the SDK and shared conformance checks verify exactly one correctly attributed exception event with the required status and timestamp behavior.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
What would you like?
Record the execution exception on both the terminal Invocation span and the Workflow span, in both Execution and Invocation views, when an uncaught handler error makes the durable execution finish with FAILED.
A handler that raises RuntimeError("Intentional execution failure") before starting any durable operation currently produces two ERROR spans with a status description but no exception event. The same gap occurs in a chained-invoke target raising RuntimeError("Intentional chained-invoke target failure") outside any durable operation. In X-Ray, the target spans have fault: true but no cause.exceptions or original error message.
The existing public OTel cases otel-execution-19 / otel-invocation-19 and the targets of otel-execution-18 / otel-invocation-18 exercise these scenarios. A local check with the real InMemorySpanExporter, both plugins, and both error messages also produced ERROR, the correct status description, and events=[] for Workflow and Invocation.
Possible Implementation
InvocationEndInfo.error already supplies an ErrorObject containing the original type/message and any available stack metadata. Add standard exception recording to both spans' FAILED finalization branches using that supplied metadata. Reuse the existing error-object event helper, coordinated with #886, rather than constructing a generic exception that changes the original type or manufactures a stack.
Inspected at commit 44b9f4d1c862b50041423e19fe6a250bbf7bd72f:
- Execution view: Workflow finalization and Invocation finalization in the same file.
- Invocation view: Workflow finalization and Invocation finalization in the same file.
The omission is also present in the inspected 4625d01bbfa97da67050014851af7eb41c61a842 revision, which provides the shared record_error_object_exception helper for operation/attempt events.
Acceptance criteria
- Both views retain ERROR status and record exactly one SDK-generated
exceptionevent for the known execution failure on each terminal Invocation and Workflow span. - Preserve the supplied exception type and original message, plus stacktrace when available. Missing stack metadata must not create a synthetic traceback; recovering frames not supplied by core is outside this request.
- Cover direct handler failure and the failed chained-invoke target. Assert the target's own span diagnostics independently of the caller's invoke span.
- Cover failure after a durable suspension and resume: completed work is skipped, one logical Workflow span is emitted only on terminal completion, and neither logical span gains duplicate exception events. Duplicate exports of the same span identity do not count as additional spans or events.
- A caught operation failure followed by successful handler completion keeps Workflow and Invocation successful without adding that caught error's exception. Existing operation/attempt diagnostics remain intact.
- Preserve PENDING/RETRYING status and export semantics. Use the final invocation outcome supplied to the hook, including cases where checkpoint-token loss converts a provisional failure into PENDING. Do not invent an exception when error details are unavailable.
- Keep event timestamps inside the corresponding spans and coordinate with the timestamp behavior in #853.
- Add focused SDK regression tests and satisfy the linked shared conformance requirement for both views and the supported OTLP/X-Ray representations.
Is this a breaking change?
No. This adds diagnostic events without changing handler behavior, public APIs, checkpoint contents, retries, or replay. Document the observable addition for telemetry consumers.
Does this require an RFC?
Yes, for agreement on the shared telemetry behavior and conformance expectations across SDKs.
Additional Context
The Java OTel implementation already records the execution error on Workflow and Invocation. This request defines the corresponding explicit contract for Python and JavaScript.
The shared conformance Span model currently has no exception-event representation, and its normalizers discard OTLP events and X-Ray cause.exceptions. ERROR-only assertions therefore cannot detect this gap. The associated requirement needs to extend that model/normalization and assert the exception details.
Related work: #853 covers operation/attempt terminal statuses and event timing; #886 covers stacktrace-presence semantics for supplied metadata. This request adds the missing execution-scope Workflow/Invocation events and their shared conformance coverage.
Shared conformance requirement: https://github.com/aws/aws-durable-execution-conformance-tests/issues/178
JavaScript counterpart: https://github.com/aws/aws-durable-execution-sdk-js/issues/1135
- Lingua principale
- Python
- Stelle
- 58
- Fork
- 32
- Merge medio
- 1g 6h
- PR unite (30g)
- 80
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di aws/aws-durable-execution-sdk-python
-
enhancement needs-triage
Difficoltà 1/5 1-3 ore Idoneità per principianti 72/100
aws/aws-durable-execution-sdk-python#927 ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
aws/aws-durable-execution-sdk-python#875 ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
aws/aws-durable-execution-sdk-python#794 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 3/5 1-2 giorni Idoneità per principianti 58/100
aws/aws-durable-execution-sdk-python#921 ·
I maintainer di solito rispondono entro 1 giorno
-
[Bug]: JS examples CI still invokes Jest after Vitest migrationForse già presa Una pull request collegata a questa issue è aperta o già unita. Apertabug needs-triage
Difficoltà 3/5 1-2 giorni Idoneità per principianti 55/100
aws/aws-durable-execution-sdk-python#918 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di aws/aws-durable-execution-sdk-python
Issue simili
-
physical
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
antonyrag/ragleap-core#1339 ·
-
enhancement good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 83/100
AllenCell/SubCellSeg#5 ·
-
[🐛 Bug]: oidc_authverifier.py strips trailing slash causing "Invalid token: Invalid issuer" errorAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
keephq/keep#6934 · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno
-
bug game: 01008BA02525A000 ios
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
-
needs-triage
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 87/100
gke-labs/kube-agents#5501 ·
I maintainer di solito rispondono entro 1 giorno