Generic WebSocket message registration never drains pre-listener frames
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 70/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- javascript, rust
- Ambito
- networking
Direzione di ricerca
Leggi il ramo generico del client js_ws_on e l’implementazione specifica del ricevitore js_ws_on_client_i64, concentrandoti su come gestiscono WsConnection.messages. Esegui o aggiungi la regressione Rust che memorizza nel buffer due frame prima della registrazione e verifica che entrambi diventino eventi in sospeso nell’ordine corretto. Il lavoro è completato quando la registrazione generica usa il comportamento condiviso per i frame memorizzati nel buffer; lascia aperta la issue per ripetere i test durante il deployment.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
The generic js_ws_on client branch registers a message callback but never drains WsConnection.messages. The receiver-specific js_ws_on_client_i64 does drain it. This loses the initial MB24 auction subscription when the native HTTP handshake completes before the async session lookup registers the callback.
Reproduction: establish an HTTP-upgraded WebSocket, send a text frame before registering the message listener, then register through js_ws_on. The frame remains buffered forever; a later identical frame reaches the listener. A Rust regression inserts two buffered frames and verifies that generic registration moves both into pending events in order.
Native MB24 trace: two initial subscriptions are sent by browsers; both authenticated connections register; neither message callback runs; a later committed bid publishes to an absent topic bucket. Five other browser scenarios pass. Re-sending the subscription restores delivery. This persists with #10028's separate GC-root fix applied.
Route generic client registration through the receiver-specific implementation so both entry points share the buffered-frame behavior. Keep this issue open for deployment retesting.
- Lingua principale
- Rust
- Stelle
- 4.9k
- Fork
- 166
- Merge medio
- 2h 20m
- PR unite (30g)
- 916
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di PerryTS/perry
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 3/5 1-2 giorni Idoneità per principianti 67/100
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 56/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di PerryTS/perry
Issue simili
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
metasequoiaime/msime#9113 ·
I maintainer di solito rispondono entro 1 giorno
-
area:desktop priority:p2 type:chore
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
I maintainer di solito rispondono entro 1 giorno
-
area: supply-chain
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 73/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
-
Refresh stale docsAperta
Difficoltà 1/5 1-3 ore Idoneità per principianti 67/100
OpenCarControls/firmware#35 ·