AppEvaluationFailed: cache.forAccount() puts OAuth grant fields in cache keys and exceeds the 8 KB keyBytes limit (Cloudflare MCP) #2146

Activity

1. ntindle commented on Oct 8, 2026

   

   ntindle

   on Oct 8, 2026

   More actions

   Another way the same defect shows up, on 2.0.0-beta.8 self-host: the cache key changes on every call, so an app's cache fills to the 128 MB totalBytes limit, and from then on every call to that app fails.

   Setup. MCP apps (Linear's and PostHog's servers) whose provider sets hosts, so the token reaches app code as a sealed handle, with the usual pattern:

   mcpRouter({
     url: MCP_URL,
     cache: cache.forAccount(account),
     accountId: account.id,
     headers: { Authorization: "Bearer " + account.fields.access_token },
     signal,
   })

   What we saw

   • After working for a while, every call to the app returns AppEvaluationFailed: "The app threw CacheError: CacheError was thrown without a message". The reason is not shown.
   • The Linear app's cache usage row (executor_cache_usage) read 127,994,086 bytes in 41,110 entries, against totalBytes: 128e6. Every entry had a different version.
   • Linear's catalog is 86 entries (about 266 KB). The same 86 entry sizes each appear 478 times, so the cache held 478 copies of one catalog. 464 of them were written in one hour of heavy use (many agents calling the app in parallel).
   • The PostHog app filled the same way: 127,819,507 bytes in 9,273 entries.
   • Three more apps built the same way were filling the same way (42 to 94 copies each) and stopped growing once cache was removed. Two quick-added apps (no hosts, token readable by app code) hold one copy each.

   Likely cause. As above, the catalog key fingerprints headers, token included. With hosts set, the Authorization header holds the sealed handle, which appears to differ on every invocation, so no key repeats: each call writes the whole catalog again and nothing is read back, until retention or the size limit. If so, the workaround above (cache instead of cache.forAccount(account)) would not help apps with hosts, since the header is still in the key (not tested).

   Expected, in addition to the above

   • The key should not depend on credential material at all (the forAccount docs say token renewal keeps the entries).
   • A full cache should evict old entries, or the app should run without the cache, rather than fail every call.
   • The CacheError should carry its reason (capacity here).

   Workaround. Remove cache from mcpRouter. The apps then list the catalog on each call (about 1.5 s for Linear) and work.
2. RhysSullivan commented on Oct 9, 2026

   

   RhysSullivan

   on Oct 9, 2026

   Collaborator

   More actions

   Thanks for the detailed report and the follow-up.

   This is fixed in 2.0.0-beta.5. cache.forAccount(account) now scopes entries by the account's ID and credential generation only. Credential fields never go into the scope or key, so a large OAuth grant like Cloudflare's 384 scopes no longer pushes keys past the 8 KB limit. The MCP catalog key is now just the server URL. Headers, including sealed hosts handles, only pick the account's scope and are never part of the key. That should also stop the repeated catalog copies you saw with Linear and PostHog. Token renewal keeps the entries, as the docs describe.

   To pick it up, upgrade to beta.5 or later (beta.6 is current). After that, you can put cache: cache.forAccount(account) back in mcpRouter.

   The two remaining points, CacheError not showing its reason and a full cache failing every call, are tracked in #2229. Closing this one.

   Sent from my Claude
3. RhysSullivan

   closed this as completedon Oct 9, 2026