Implement negotiation tracking based on offerId#1927
Conversation
🦋 Changeset detectedLatest commit: 7ab4e09 The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
size-limit report 📦
|
…js into lukas/negotiaton-loo
1egoman
left a comment
1egoman
left a comment
There was a problem hiding this comment.
Generally the whole approach makes sense to me!
| setTimeout(() => pub.answer(1), 10); // does not satisfy checkpoint=1 | ||
| setTimeout(() => { | ||
| const id = pub.startOffer(); // 2 | ||
| pub.answer(id); | ||
| }, 30); |
There was a problem hiding this comment.
thought: Two things:
- I wonder if there's a way to do a lot of these same testing scenarios without explicit sleeps. Are the lengths of these delays meaningful here, or is the goal just to have a series of events all occur in a defined order all on their own event loop macrotasks?
- I think linearizing these would make the tests a bit easier to follow, so you could scan the test top to bottom and have to jump between different functions which get scheduled to run at different times. ie, something like:
// Some sort of explanation here
// does not satisfy checkpoint=1
pub.answer(1);
await sleep(20); // Or ideally if the delay isn't important, `sleep(0)` / `setImmediate`.
// Some sort of explanation here
const id = pub.startOffer(); // 2
pub.answer(id);There was a problem hiding this comment.
yeah, that probably makes things clearer, will change it to this pattern
| // Race: an answer past our checkpoint already arrived before we had a | ||
| // chance to subscribe. | ||
| if (this.publisher.latestAcknowledgedOfferId > checkpoint) { | ||
| resolve(); | ||
| return; |
There was a problem hiding this comment.
suggestion: Maybe it's worth logging here so that it would be evident that there's a lot of spurious renegotiation occurring in the context of other issues? Not sure.
|
|
||
| describe('PCTransportManager.negotiate', () => { | ||
| let originalRTCPeerConnection: unknown; | ||
|
|
||
| beforeEach(() => { |
There was a problem hiding this comment.
Really glad to see some tests here for this! Looking forward to seeing this grow moving forward.
2 participants
Fix publisher negotiation hang under stacked offer cycles
Under specific conditions the Promise returned by
setCameraEnabled(true)could neither resolve nor reject, even though the track was successfully published from the server's perspective. Sessions hitting this also showed MaxListenersExceededWarning for negotiationComplete/negotiationStarted on the publisher within seconds of connecting.Root cause
PCTransportManager.negotiate()resolved on the next NegotiationComplete event from the publisher. That event only fires when an answer is processed andrenegotiate === false. If a newpublisher.negotiate()lands while an offer is in flight, the next answer recurses into another offer instead of emitting NegotiationComplete (PCTransport.ts:239-243). With enough cycle starts (data-channel sends, server-driven MediaSectionsRequirement, concurrent track publishes) the cycle never converges, the resettable timeout from #1813 keeps firing, and the Promise wedges. cleanup() also never offed theonce(NegotiationComplete)listener, which is why the warning surfaced.Change
Switch from an event-cycle-based wait to an offerId checkpoint:
checkpoint = publisher.latestOfferIdat the momentnegotiate()is called.PCEvents.OfferAnsweredfires for every successful answer, including ones that recurse via renegotiate=true (which the existing NegotiationComplete deliberately suppresses).cleanup()— no leaks across abort/timeout/error paths.Tests
PCTransportManager.test.ts covers:
Risk
Behavior change is contained to the publisher negotiation handshake.
latestOfferIdis exposed publicly (was private) and latestAcknowledgedOfferId is added — both internal SDK fields. No public API surface changes.