Skip to content

net/http: race between operations on maxClientStreamID and inGoAway. #51309

Closed
@doujiang24

Description

@doujiang24

What version of Go are you using (go version)?

$ go version
go version go1.17.2 darwin/amd64

Does this issue reproduce with the latest release?

yeah, maybe. I haven't reproduced it yet.
Just found this issue based on code.

race may happen on such a flow:


 fields                                 write goroutine                       read goroutine

                                                                         1. read(false), in processHeaders
inGoAway
                                       2. set to true, in goAway
----------------------------------------------------------
                                       3. read(old), in scheduleFrameWrite 
maxClientStreamID
                                                                        4. set(a new), in processHeaders

The server may have already processed the new request while the client got the old stream id in the GoAway frame,
and the client will retry the new request again.

Yeah, the race is very very small, but I think it indeed exists in theory.
eg. these three things happen at the same time:

  1. server received a request header,
  2. server got a signal to start graceful stop,
  3. an OS schedule on the read goroutine between operation 1 and operation 4(make it is long enough time).

Or, do I misunderstand the code?
Thanks!

Metadata

Metadata

Assignees

No one assigned

    Labels

    FrozenDueToAgeWaitingForInfoIssue is not actionable because of missing required information, which needs to be provided.

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions