[Bug]: Execution OTel view retains the ended attempt spanId in MDC
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 54/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- java
- Ambito
- observability, testing
Direzione di ricerca
Read ExecutionOtelPlugin.java around the Execution-view start and End hooks, then compare the MDC cleanup in InvocationOtelPlugin.java. Start by tracing scope and MDC handling across normal completion, failure, early returns, nested context, and suspension/resume. Add focused lifecycle assertions immediately after the End hook returns with MDC enabled, and verify that trace context is preserved and MDC-disabled behavior remains unaffected.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Expected Behavior
After ExecutionOtelPlugin.onUserFunctionEnd closes a completed attempt's OTel scope, MDC should no longer identify that ended attempt as the current span. Cleanup should happen before the hook returns, while preserving valid surrounding trace context.
Actual Behavior
Public main at 1c4922293d01bbd3a18082f0d9ea819a361a2227 injects the attempt span into MDC at user-function start, but the Execution-view End hook closes the OTel scope without removing its spanId from MDC. The Invocation-view End hook explicitly removes that key.
- Execution-view start hook: makes the attempt span current and injects MDC.
- Execution-view End hook: closes
attemptScopes, handles early returns, and ends the attempt span without removing the MDC span ID. - Invocation-view End hook: calls
MDC.remove(MdcSpanEnricher.MDC_SPAN_ID)when MDC enrichment is enabled, before early returns. - Execution-view invocation cleanup: clears MDC at invocation end.
This creates a potential post-attempt correlation window in which a log can retain the ended attempt's span ID until later cleanup. The scope of this report is the missing cleanup at the End-hook boundary, not a claim of permanent or cross-invocation leakage.
Steps to Reproduce
This report is based on public source inspection. The following runtime validation recipe has not been executed for this report:
- Configure the Execution OTel view with MDC enrichment enabled, a recording provider, and an MDC-capable SLF4J binding.
- In a focused lifecycle test, begin an invocation, an operation, and its user-function attempt on the owning thread. Record the attempt's span ID from MDC.
- Complete the user function and inspect
MDC.get("spanId")immediately afteronUserFunctionEndreturns, before any enclosing logger scope or invocation cleanup runs. Compare it withSpan.current(). - Repeat with the Invocation view configured separately as a control.
Expected: MDC no longer reports the ended attempt's span ID. The source shows that only the Invocation-view End hook explicitly removes it.
SDK Version
Java SDK otel-plugin, public main at 1c4922293d01bbd3a18082f0d9ea819a361a2227.
Java Version
Not applicable to source inspection; no runtime reproduction was run for this report.
Is this a regression?
Unknown; no last working version has been established.
Acceptance Criteria
- Remove or correctly restore the completed attempt's MDC span context before the Execution-view End hook returns; retain appropriate trace-level correlation.
- Add a focused assertion immediately after the hook, before enclosing logger-scope cleanup can mask the defect. Cover normal completion, failure, and relevant early-return paths with MDC enabled.
- Verify nested context restoration and suspension/resume, with the Invocation view as a control and MDC-disabled configurations unaffected.
- Lingua principale
- Java
- Stelle
- 28
- Fork
- 16
- Merge medio
- 2g 17h
- PR unite (30g)
- 56
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-java
-
documentation pkg:sdk
Difficoltà 1/5 1-3 ore Idoneità per principianti 88/100
aws/aws-durable-execution-sdk-java#645 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
aws/aws-durable-execution-sdk-java#300 ·
I maintainer di solito rispondono entro 1 giorno
-
[Epic]: Durable Functions on LMIForse già presa @zhongkechen l’ha presa 10 giorni fa. Aperta
aws/aws-durable-execution-sdk-java#798 · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 5/5 Più di una settimana Idoneità per principianti 8/100
aws/aws-durable-execution-sdk-java#787 ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement pkg:sdk
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
aws/aws-durable-execution-sdk-java#779 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di aws/aws-durable-execution-sdk-java
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
strimzi/strimzi-kafka-operator#13328 · 1 commento · 3 reazioni ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
OpenLiberty/ci.maven#2137 ·
I maintainer di solito rispondono entro 1 giorno
-
Payer adjustment can exceed the balance left after copay and deductible, so claim payments add up to more than the chargeForse già presa @DG47 l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 79/100
synthetichealth/synthea#1772 ·
I maintainer di solito rispondono entro 13 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
geonetwork/core-geonetwork#9592 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
NationalSecurityAgency/ghidra#10040 ·
I maintainer di solito rispondono entro 2 giorni