Repository navigation
fix(worker): open a handle scope per delivered message, and fix two messaging specs - #545
Conversation
…essaging specs WorkerWrapper's drain dispatches a whole batch of queued messages under one HandleScope and Worker::OnMessageCallback opened none of its own, so the handles made while delivering every message in a batch stayed alive until the batch ended. It now opens its own scope, as the comment on SerializedValue::Deserialize already says each caller does. The on() + once() spec started its settle timer at the third reply while expecting four, so it failed whenever the fourth reply took longer than the settle window; it now waits for the fourth. The DOMException structuredClone canary now also asserts that a caller-set stack survives the clone.
|
No actionable comments were generated in the recent review. Walkthrough
Merge Risk:
|
What's wrong
WorkerWrapper's drain dispatches a whole batch of queued messages under oneHandleScope, andWorker::OnMessageCallbackopened none of its own. So every handle made while delivering each message in a batch (the deserialized payload, its ports, the event, and whatever the listeners allocate) stayed alive until the batch ended. The comment onSerializedValue::Deserializealready says each caller opens a scope per message. The parent-side post andNativeMessagePort::Draindo; the worker-side drain didn't.SETTLE. Its comment also had the two registrations swapped.structuredClonecanary only checked the stack the constructor generates, never a stack set by the caller.The fix
Worker::OnMessageCallbackopens aHandleScopeper message.stackand asserts that the clone carries it.Tests
Full suite on an iPhone 16 Pro simulator (
./run_tests.sh): 1824 specs, 0 failures. That run was before rebasing onto #544, which adds one spec.Same fixes on Android: NativeScript/android#2090
Summary by CodeRabbit