Skip to content

chore: merge upstream/main (baf14b9, unique operationIds) - #1

Merged
nagaame merged 3 commits into
mainfrom
sync/upstream-main-baf14b9
Sep 20, 2026
Merged

nagaame merged 3 commits into
mainfrom
sync/upstream-main-baf14b9

Conversation

@nagaame

@nagaame nagaame commented Sep 20, 2026

Copy link
Copy Markdown

Why

Fork sync: merge google/gnostic baf14b9 ("fix: operationId must be unique (google#478)")
into main.

main was 10 commits ahead / 1 behind the merge-base e0e09f7, so this is a real merge
commit — a fast-forward, the web "Sync fork" button and a plain git pull cannot do it.
Upstream's change: the 2nd and later http rules of a method now emit
operationId: <op>_<N> so operationIds stay unique (OpenAPI v3.0.3 4.7.10.1).

Conflict resolution

cmd/protoc-gen-openapi/generator/generator.go (1 hunk): the @sse feature (7922890)
added an isSSE argument to buildOperationV3, while baf14b9 switched the very same
call site to the new opID variable. Both changes are kept:

op, path2 := g.buildOperationV3(
    d, opID, service.GoName, comment, defaultHost, path, body, inputMessage, outputMessage, isSSE)

.../additional_bindings/openapi.yaml auto-merged: the infoURL line and upstream's
Messaging_UpdateMessage_2 line are far apart.

Fixture follow-up (2nd commit)

baf14b9 updates upstream's own additional_bindings/openapi.yaml, but this repo also
checks in the fq_schema_naming / json / string_enum / default_response variants for
every test dir, and plugin_test.go diffs every fixture that exists. Those four still
encoded the duplicate operationId and failed. Regenerated via GENERATE_FIXTURES=true
(4 files, 1 line each) — identical to upstream's own fixture change.

Verification

$ go build -mod=vendor ./...            # exit 0
$ go test  -mod=vendor -count=1 ./...   # ok=17  FAIL=0

The four previously failing subtests (TestOpenAPIFQSchemaNaming, TestOpenAPIJSONNaming,
TestOpenAPIStringEnums, TestOpenAPIDefaultResponse — all Additional_Bindings) pass.

Net diff against main is exactly 6 files and contains nothing beyond upstream's own patch
plus those 4 fixture lines: no fork customization was lost.

⚠️ Merge with a merge commit, not squash

This branch carries a real merge commit (a08ae5a) whose second parent is baf14b9.
Squash-merging would drop baf14b9 from main's ancestry, leaving the merge-base at
e0e09f7 — every future git merge upstream/main would then re-deliver that commit and
re-examine everything since e0e09f7. Merge commit also matches how this repo synced
upstream before (562c644).

sloretz and others added 3 commits August 10, 2026 17:13
Signed-off-by: Shane Loretz <sloretz@intrinsic.ai>
Brings google/gnostic baf14b9 "fix: operationId must be unique (google#478)" into
the fork: the 2nd and later http rules of a method now get an "_N" suffix so
operationIds stay unique (OpenAPI v3.0.3 4.7.10.1).

Conflict resolution in cmd/protoc-gen-openapi/generator/generator.go:
the fork's @sse feature (7922890) added an `isSSE` argument to
buildOperationV3, while baf14b9 switched the same call site to the new
`opID` variable. Both changes are kept - the call site now passes `opID`
together with `isSSE`. `fmt` was already imported on the fork side.

additional_bindings/openapi.yaml auto-merged: the fork's infoURL change and
upstream's `Messaging_UpdateMessage_2` change are on different lines.
Follow-up to the upstream merge: baf14b9 makes the 2nd and later http rules
of a method emit operationIds with an "_N" suffix, but only upstream's own
openapi.yaml fixture was updated. The fork additionally checks in the
fq_schema_naming / json / string_enum / default_response variants for every
test dir, and plugin_test.go diffs every fixture that exists, so those four
still encoded the old duplicate id and failed.

Regenerated with GENERATE_FIXTURES=true, then set back to false
(TestGenerateFixturesIsFalse guards the flag). The diff is exactly 4 files,
1 line each, matching upstream's own fixture change.
@nagaame
nagaame merged commit 50ee74f into main Sep 20, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants