fix(runtime): serve /discovery with Cache-Control: no-store (cloud#152)#1963
Merged
Conversation
The discovery payload reflects MUTABLE runtime config — notably `routes.mcp`,
which is only advertised when OS_MCP_SERVER_ENABLED=true. getDiscoveryInfo()
(and isMcpEnabled(), which reads process.env fresh) recompute it correctly on
every request, but the two discovery routes (`/.well-known/objectstack` and
`${prefix}/discovery`) emitted no Cache-Control header, so an edge/CDN could
cache the response. After MCP was enabled on a staging env, GET /discovery kept
returning `routes.mcp: undefined` (stale, even with cache-busting query params),
so the objectui Integrations page rendered "MCP not enabled" against a live MCP
server.
Mark both discovery routes `Cache-Control: no-store` so the payload is never
cached — config changes (enable MCP, add a plugin/service) are reflected
immediately. +regression test asserting the header on both routes.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
📓 Docs Drift CheckThis PR changes 1 package(s): 17 hand-written doc(s) reference the affected code and may need an implementation-accuracy re-verification:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bug (cloud#152)
Discovery reflects mutable runtime config —
routes.mcpis only advertised whenOS_MCP_SERVER_ENABLED=true. But the discovery routes set noCache-Control, so an edge/CDN can cache the response. On a staging env, after enabling MCP,GET /api/v1/discoverykept returningroutes.mcp: undefined(stale, even with cache-busting query params) whilePOST /api/v1/mcpcorrectly served — so the objectui Integrations page showed "MCP not enabled" against a live server.Root cause
getDiscoveryInfo()(http-dispatcher.ts) andisMcpEnabled()(readsprocess.envfresh) recompute the payload correctly per request — the in-app value is never stale.buildSecurityHeaders()sets noCache-Control(itsmax-ageis HSTS). So the only staleness is the HTTP cache layer.Fix
Mark both discovery routes (
/.well-known/objectstack+${prefix}/discovery)Cache-Control: no-store.res.header()is the same emit method the adjacent no-cache routes use. +regression test asserting the header on both routes.Test
@objectstack/runtimebuilds clean;dispatcher-plugin.routes.test.tsgreen (4/4, incl. the new no-store assertion).Note: the actual CF-edge cache only clears once cloud bumps
.framework-shato this and deploys to staging.🤖 Generated with Claude Code