partyserver: with hibernation off, a closing socket removes a newer connection with the same id from getConnections(), so that client stops receiving broadcasts

Aperta Adatta ai principianti
  • Qualcosa non va?
#430 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
82/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
backend

Direzione di ricerca

Inizia da InMemoryConnectionManager.accept e removeConnection, dove l’issue identifica la voce della map e il listener di chiusura/errore. Controlla i test per la sostituzione delle connessioni e gli eventi di chiusura ritardati, poi verifica che la chiusura di un socket precedente lasci disponibile la connessione più recente tramite getConnections(). Il lavoro è completato quando la connessione sostitutiva continua a ricevere broadcast dopo la chiusura del socket precedente.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

InMemoryConnectionManager.accept stores connections in a Map keyed by connection.id. Its close/error listener runs this.#connections.delete(connection.id) without checking that the entry is still that connection.

y-partyserver's YProvider sends one _pk (from connectionId, or nanoid(10) once per provider) on every reconnect. So a client that reconnects while the server still holds its old socket replaces the map entry. When the old socket's close arrives later, the delete removes the new, live connection. From then on getConnections() never yields it. The client keeps sending and the server keeps applying its updates, but no broadcast reaches it: with y-partyserver that is every document update and every awareness change from the other peers. Nothing tells the client, and the provider has no watchdog for a silent socket, so it stays deaf until it reconnects for some other reason.

Repro (partyserver 0.5.10, y-partyserver 2.2.0, wrangler 4.159.0, compatibility date 2026-11-01, hibernate: false, via unstable_startWorker). A and B are YProviders in one room:

  1. Open a raw WebSocket to the room with ?_pk=<A.provider.id>. It stands in for an old socket the server has not seen die yet.
  2. Connect A, then terminate the raw socket and wait 1.5 s.
  3. A's updates still reach B. But within 3 s, none of these reach A: B's updates, B's awareness change, and the updates of a newcomer C.

The result is the same when the raw socket opens after A. Without the raw socket, all of these checks pass.

Suggested fix: in removeConnection, delete only when this.#connections.get(connection.id) === connection. The older socket then leaves the map as soon as it is replaced, which fits: it is the stale one.

Lingua principale
TypeScript
Stelle
1.3k
Fork
84
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di cloudflare/partykit

Tutte le issue di cloudflare/partykit

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.