Socket writes an entry for a DDP subscription on two different paths, and keeps nothing that tells them apart afterwards.
- On a
ready DDP response, subscribe records the DDP subscription under the id the server confirmed.
- When the connection ends the wait first, the same DDP subscription is recorded anyway — an Abandoned sub, kept so it can be re-established under the id it was sent with.
The recorded entry carries { id, name, params, unsubscribe, onEvent }. There is no status on it. The ready DDP response is consumed to settle the send that was waiting on it, and is never stored.
So a recorded DDP subscription does not prove the server confirmed it, and the confirmed case is indistinguishable from the abandoned one.
Where this shows up
DDPDriver.waitForNotifyUserMediaSubs polls the record every 100ms until entries for both media streams appear, then re-sends the sub under the existing id. It does that because a fresh DDP response is the only proof of readiness available. It resolves a boolean and never rejects.
#298 proposes a whenReady(name, params) query on the extracted collaborator. That query cannot be written against what is recorded today — the readiness state it would read does not exist yet, so it has to be designed first. The same gap sits underneath the subscription piece in #296 and #278.
Open questions
- What counts as ready for an Abandoned sub that is later re-established?
- Is readiness a recorded flag, or a promise a caller can wait on?
- Does re-sending the
sub stay the readiness mechanism, or does it go away once readiness is recorded?
- The suite in
lib/drivers/__tests__/ pins the current record's shape, including tests that write entries by hand. What of that is behavior worth keeping?
This is a behavior change, so it likely deserves an ADR next to 0004 and 0005 rather than being decided inside a pull request.
Socketwrites an entry for a DDP subscription on two different paths, and keeps nothing that tells them apart afterwards.readyDDP response,subscriberecords the DDP subscription under the id the server confirmed.The recorded entry carries
{ id, name, params, unsubscribe, onEvent }. There is no status on it. ThereadyDDP response is consumed to settle thesendthat was waiting on it, and is never stored.So a recorded DDP subscription does not prove the server confirmed it, and the confirmed case is indistinguishable from the abandoned one.
Where this shows up
DDPDriver.waitForNotifyUserMediaSubspolls the record every 100ms until entries for both media streams appear, then re-sends thesubunder the existing id. It does that because a fresh DDP response is the only proof of readiness available. It resolves a boolean and never rejects.Why it blocks #296 / #298 / #278
#298 proposes a
whenReady(name, params)query on the extracted collaborator. That query cannot be written against what is recorded today — the readiness state it would read does not exist yet, so it has to be designed first. The same gap sits underneath the subscription piece in #296 and #278.Open questions
substay the readiness mechanism, or does it go away once readiness is recorded?lib/drivers/__tests__/pins the current record's shape, including tests that write entries by hand. What of that is behavior worth keeping?This is a behavior change, so it likely deserves an ADR next to 0004 and 0005 rather than being decided inside a pull request.