Fix span reporting when actor aborts with pending waitUntil tasks

[mar-cf]

The span attached to a subrequest is held by the fetch promise, which can be passed to waitUntilTasks. When an actor aborts while another request's waitUntil task is still pending, span duration may be incorrect. Span reporting relies on timing from the current request.

If there are reasons not to reorder ~IncomingRequest to cancel pending operations before removing from the list, we can reconsider the assumption that an active request is available during that time.

[mar-cf]

Tests build on tests added in another change, so ignore the base until that's merged.

[mar-cf]

cc @kentonv I see you added this originally, so I plan to request your review after I get some buy in from Felix.

[fhanau]

The span attached to a subrequest is held by the fetch promise, which can be passed to waitUntilTasks. When an actor aborts while another request's waitUntil task is still pending, span reporting can partially fail. Span reporting relies on timing from the current request.

The description is misleading here – span reporting doesn't "partially fail", we merely fall back to the return event timestamp as the IncomingRequest was removed prematurely. The span metadata will still be reported in full, only the timestamp may be off.

[fhanau]

This lines up with what I had in mind for this issue as described in #5282 (comment) – it should solve the issue at hand but I can't rule out that reordering actions in ~IoContext_IncomingRequest would cause other issues, maybe there was a reason for having the current order, which looks less intuitive than the one being proposed here.

[mar-cf]

The span attached to a subrequest is held by the fetch promise, which can be passed to waitUntilTasks. When an actor aborts while another request's waitUntil task is still pending, span reporting can partially fail. Span reporting relies on timing from the current request.

The description is misleading here – span reporting doesn't "partially fail", we merely fall back to the return event timestamp as the IncomingRequest was removed prematurely. The span metadata will still be reported in full, only the timestamp may be off.

Updated desc.

[codspeed-hq]

CodSpeed Performance Report

Merging #5709 will degrade performances by 8.86%

_{Comparing mar/stw-span-without-request (5a7b8eb) with main (117eda7)}

Summary

❌ 1 regression
✅ 56 untouched
⏩ 34 skipped¹

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
❌	simpleStringBody[Response]	19.6 µs	21.5 µs	-8.86%

Footnotes

1. 34 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩