Persist connection health verdicts on failure and always send ifStaleMs

[RhysSullivan]

Problem

When a connection's authorization server stopped re-minting its credential, the connection health endpoint answered with a bare 500 instead of a verdict, and the client kept asking. Two halves:

• Server — connectionCheckHealth persisted a verdict only on the success path, and a credential-resolution failure whose code was not invalid_grant was converted into a storage failure. So a connection with a broken credential never got a last_health row, and every probe failed the request.
• Client — revalidateQuery sent ifStaleMs only for healthy verdicts, so the server-side freshness gate was bypassed for exactly the connections that were failing. The client's once-per-mount guard is per mount, not per connection, so every surface rendering a broken connection sent its own refresh grant to an upstream that was already refusing.

In production a handful of broken connections produced hundreds of server errors on the health endpoint plus unbounded refresh traffic to third-party token endpoints.

Fix

Both health paths — credential-only and probing — now fold a credential-resolution failure through the single healthFromCredentialResolutionFailure mapping and persist the resulting expired/degraded verdict; the divergent healthFromCredentialResolutionError is deleted. The failure channel stays reserved for genuine storage faults, so an infra blip still fails the request rather than persisting as a verdict. The hook always sends ifStaleMs: the long window for a healthy verdict, a short 30s window for anything else.

Testing

Two e2e scenarios in e2e/scenarios/connection-health-verdict.test.ts (run on the cloud target), one per half of the symptom. Both complete a real authorization-code flow against a test authorization server that refuses every refresh, with a health check declared on the integration so the connection takes the probing path.

API scenario — the server half:

• the health request returns a degraded verdict carrying the AS's reason, not a failed request;
• the verdict is persisted on the connection;
• three repeat checks inside the freshness window return that same verdict, and the AS's request ledger shows no further refresh grant;
• a second connection whose grant is revoked (invalid_grant) reads expired and persists too.

Browser scenario — the client half, driven only by navigation between the two surfaces a user actually visits (integration page, integrations list, back again). After the first surface's probe is the baseline, the authorization server's ledger shows no further refresh grant, while the app is still asking — and every automatic health request carries an ifStaleMs window.

Red against pre-fix product code: the API scenario's health request fails with an InternalError; reverting only the hook leaves the browser scenario failing on the ledger (extra refresh grants) and on the missing ifStaleMs.

One unit test remains, packages/react/src/lib/use-connection-health.test.ts, pinning the exact window widths per verdict status — cheaper than a browser run per status. The server-side unit tests that duplicated the scenario were removed.

Out of scope, deliberately: refresh classification itself, the persistent refresh cool-off, and vault write policy.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
✅ Deployment successful! View logs	executor-cloud	295359f	Aug 27 2026, 10:47 PM

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	executor-marketing	295359f	Commit Preview URL Branch Preview URL	Aug 27 2026, 10:45 PM

[github-actions]

Cloudflare preview

Torn down — the PR is closed.

[pkg-pr-new]

Open in StackBlitz

@executor-js/cli

npm i https://pkg.pr.new/@executor-js/cli@1777

@executor-js/config

npm i https://pkg.pr.new/@executor-js/config@1777

@executor-js/execution

npm i https://pkg.pr.new/@executor-js/execution@1777

@executor-js/sdk

npm i https://pkg.pr.new/@executor-js/sdk@1777

@executor-js/codemode-core

npm i https://pkg.pr.new/@executor-js/codemode-core@1777

@executor-js/runtime-quickjs

npm i https://pkg.pr.new/@executor-js/runtime-quickjs@1777

@executor-js/plugin-file-secrets

npm i https://pkg.pr.new/@executor-js/plugin-file-secrets@1777

@executor-js/plugin-graphql

npm i https://pkg.pr.new/@executor-js/plugin-graphql@1777

@executor-js/plugin-keychain

npm i https://pkg.pr.new/@executor-js/plugin-keychain@1777

@executor-js/plugin-mcp

npm i https://pkg.pr.new/@executor-js/plugin-mcp@1777

@executor-js/plugin-onepassword

npm i https://pkg.pr.new/@executor-js/plugin-onepassword@1777

@executor-js/plugin-openapi

npm i https://pkg.pr.new/@executor-js/plugin-openapi@1777

executor

npm i https://pkg.pr.new/executor@1777

commit: 295359f