This is not a bug but a design concern regarding how context cancellation is handled in ExecutorEventHandler.
Currently, the handler detaches from the parent message context using context.WithoutCancel and introduces a separate internal cancellation mechanism. This creates multiple sources of truth for cancellation and may lead to unintended side effects.
Key concerns:
Breaks context propagation: upstream cancellation signals are not respected
Dual cancellation model increases complexity and reduces clarity
Manual cancellation tracking (e.cancels) adds lifecycle management overhead
May impact observability and debugging
Expected behavior:
Preserve parent context cancellation semantics
Avoid detaching from the original context unless necessary
Prefer structured concurrency (e.g., errgroup, worker pools) over manual tracking
If this behavior is intentional, it would be helpful to understand the reasoning behind detaching from the parent context instead of preserving its cancellation semantics.
This is not a bug but a design concern regarding how context cancellation is handled in ExecutorEventHandler.
Currently, the handler detaches from the parent message context using context.WithoutCancel and introduces a separate internal cancellation mechanism. This creates multiple sources of truth for cancellation and may lead to unintended side effects.
Key concerns:
Breaks context propagation: upstream cancellation signals are not respected
Dual cancellation model increases complexity and reduces clarity
Manual cancellation tracking (e.cancels) adds lifecycle management overhead
May impact observability and debugging
Expected behavior:
Preserve parent context cancellation semantics
Avoid detaching from the original context unless necessary
Prefer structured concurrency (e.g., errgroup, worker pools) over manual tracking
If this behavior is intentional, it would be helpful to understand the reasoning behind detaching from the parent context instead of preserving its cancellation semantics.