Repository navigation
fix: regenerate broken OpenAPI documents and check them in CI - #58262
Conversation
There was a problem hiding this comment.
Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.
An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.
There was a problem hiding this comment.
Looks good. On the base, all three openapi.json files fail to parse at line 13419, the same error deploy-www hits, and protocol check:generated reports the document is stale. With this PR, the checked-in file is byte-identical to what bun run generate produces from the current ClientApi. The services/www copies match it, and both protocol and www check:generated pass. The new CI step sits correctly before the existing www check.
Public API impact: the published OpenAPI document becomes valid again and regains /api/experimental/client-mcp and /api/experimental/client-mcp/token, which were already served by the server. This is backwards compatible, and no server, SDK or client code changes.
No concerns.
deploy-wwwhas failed on everydevcommit since #58252, becausepackages/protocol/openapi.json(and the two copies inservices/www) is not valid JSON.At that line, a
locationquery schema stops after"type": "null" }and"/api/debug/heap-dump"starts. The file was merged by hand, not generated, and lost the/api/experimental/client-mcpand/api/experimental/client-mcp/tokenpaths along the way.bun run generateinpackages/protocoland then inservices/www. The result is the generator's output for the currentClientApi, including the twoclient-mcppaths and the heap-dump route.packages/protocol'scheck:generatedto the Linux unit job. CI already checked that theservices/wwwcopies matchpackages/protocol/openapi.json, but not that the file matchesClientApi, so a broken file that was copied to all three places passed.The new step fails against the current
devfile and passes with this change.Flaky update-restart tests
The two TUI tests added in #58139 (
restarting after an update…,quitting after a background update…) failed on bothunit (linux)runs of this PR. Changingtest.ymlinvalidates turbo's cache, so every package's tests run here. They waited on frames with a renderer whose frame loop never started, sowaitForFramegave up as soon as no render was scheduled while the home route was still loading:They now start the frame loop and wait for
terminalHandoff'scomplete, the same as the selection-copy test in the same file.