Skip to content

Fix field stop read in duplicate_protocol.go#3125

Merged
fishy merged 3 commits intoapache:masterfrom
winmillwill:patch-1
Apr 21, 2025
Merged

Fix field stop read in duplicate_protocol.go#3125
fishy merged 3 commits intoapache:masterfrom
winmillwill:patch-1

Conversation

@winmillwill
Copy link
Copy Markdown
Contributor

@winmillwill winmillwill commented Apr 18, 2025

When generated code reads a struct, it runs a for loop calling ReadFieldBegin at the top, but breaks if the field type ID is thrift.STOP.

With TDuplicateToProtocol naively performing an equivalent write for every read, this results in extra bytes, which breaks just about any protocol in the DuplicateTo struct field.

The proposed fix is to simply add special handling for thrift.STOP to ReadFieldBegin.

I'm no thrift expert, so I have no idea how other libraries handle this concern. Ideally, it seems like each protocol should understand and enforce the invariant that an attempt to call WriteFieldBegin with type ID 0 either isn't valid or is a misguided attempt to call WriteFieldStop, which could be performed instead, perhaps with the additional guardrail that a sequence of stops (with length > 1) never makes any sense.

  • [ x ] Did you create an Apache Jira ticket? (Request account here, not required for trivial changes)
  • [ x ] If a ticket exists: Does your pull request title follow the pattern "THRIFT-NNNN: describe my issue"?
  • [ x ] Did you squash your changes to a single commit? (not required, but preferred)
  • [ x ] Did you do your best to avoid breaking changes? If one was needed, did you label the Jira ticket with "Breaking-Change"?
  • [ x ] If your change does not involve any code, include [skip ci] anywhere in the commit message to free up build resources.

^^ hopefully we can agree this change is trivial, I very badly do not want to look at anyone's Jira, especially if it doesn't belong to my employer.

When generated code reads a struct, it runs a `for` loop calling `ReadFieldBegin` at the top, but breaks if the field type ID is `thrift.STOP`.

With TDuplicateToProtocol naively writing everything read, this results in extra writes, which breaks just about any protocol in the `DuplicateTo` struct field.

The proposed fix is to simply add special handling for `thrift.STOP` to `ReadFieldBegin`.

I'm no thrift expert, so I have no idea how other libraries handle this concern.  Ideally, it seems like each protocol should understand and enforce the invariant that an attempt to call `WriteFieldBegin` with type ID 0 either isn't valid or is a misguided attempt to call `WriteFieldStop`.
@Jens-G Jens-G added the golang patches related to go language label Apr 19, 2025
Copy link
Copy Markdown
Member

@fishy fishy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please add a test (since this needs to use a struct, the test needs to be under lib/go/test) that would catch the bug?

@winmillwill
Copy link
Copy Markdown
Contributor Author

Can you please add a test (since this needs to use a struct, the test needs to be under lib/go/test) that would catch the bug?

I have written a test in the way that made sense to me.

Co-authored-by: Yuxuan 'fishy' Wang <fishywang@gmail.com>
@fishy fishy merged commit b4d2d91 into apache:master Apr 21, 2025
20 of 22 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

golang patches related to go language

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants