Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

MockWebServer can send extra HTTP/2 stream resets before consuming queued responses

Aperta
  • Qualcosa non va?
#9,821 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
kotlin
Ambito
networking

Direzione di ricerca

Start by reading Http2SocketHandler.onStream() and dispatchBookkeepingRequest() in MockWebServer.kt, then run HttpOverHttp2Test.recoverFromMultipleRefusedStreamsRequiresNewConnection. Trace when dispatcher.dispatch(request) consumes each queued response relative to sending REFUSED_STREAM. Done means the two scripted refusals are consumed once and the retry receives "abc"; the report says the debugger was needed to reproduce the failure.

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

Descrizione

bug

Related to #9816

I was investigating HttpOverHttp2Test.recoverFromMultipleRefusedStreamsRequiresNewConnection at 67c4f34e7. The test queues two responses that reset the stream with REFUSED_STREAM, followed by a successful response containing "abc".

In Http2SocketHandler.onStream(), MockWebServer reads dispatcher.peek() and applies onRequestStart before calling dispatchBookkeepingRequest(). For CloseStream, this sends the reset before dispatcher.dispatch(request) consumes the queued response.

Since stream handlers run concurrently, a client can receive the reset and retry while the previous handler has not yet consumed its response. The retry can then observe the same queued response.

I reproduced this with a debugger:

  1. Run recoverFromMultipleRefusedStreamsRequiresNewConnection.
  2. Set a breakpoint on requestQueue.add(request) inside dispatchBookkeepingRequest() in MockWebServer.kt.
  3. Set the breakpoint to suspend only the current thread.
  4. Leave the handler suspended so the client can retry.

The client received two refusals on the original connection, opened another connection, and received a third refusal there. The call then failed with StreamResetException: REFUSED_STREAM, even though only two refusals were queued.

I would expect each scripted refusal to be consumed once, with the third attempt receiving "abc".

The breakpoint deliberately forces a delay between sending the reset and consuming the response. I haven’t reproduced this exact failure without the debugger or established whether it explains the Windows CI failure that prompted the investigation.

Environment: Arch Linux x86_64, Java 21, Gradle 9.8.2.

Lingua principale
Kotlin
Stelle
47.1k
Fork
9.3k
Merge medio
1g 11h
PR unite (30g)
35

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

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 lysine-dev/okhttp

Tutte le issue di lysine-dev/okhttp

Issue simili

Altre issue su Kotlin

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.