Local approval can misreport connector upgrade when relay session is on another server instance #471

Problem

A fresh approval for a computer-owned collection can fail with:

Update mdbase connect on this computer before approving this application.

The installed connector is already the same beta.108 release as the production server. This message conflates an actually incompatible connector with an unavailable relay session on the particular server instance handling approval.

Reproduction / bounded observations (2026-09-25)

• Reader extension, Chrome Default profile, selected Zotero Library (Local). The fresh authorization request still had about seven minutes before expiry when Set up and allow access returned the update-required message. This was not the separate expired-link failure seen on older requests.
• Signed local desktop/runtime upgraded to 0.1.0-beta.108; mdbase connect status --json reported binary_version: 0.1.0-beta.108, state: connected, and readiness.ready: true; connect doctor --json reported healthy. These local checks do not prove the production relay session was ready.
• Production /health identified revision 2203976764fcd60511965e96fd397b19dd5ad3ef (beta.108). A production request log records POST /v1/authorization-requests/<id>/approve returning HTTP 400 at 2026-09-24T23:00:23Z. The available request log did not establish which server instance handled it.
• Control case: the same Reader extension successfully approved and selected Zotero Library (hosted). No source was saved. This separates the extension's grant consumption/hosted path from the local-collection approval failure; it does not test operation with the local daemon stopped.

Code-level issue / hypothesis

At beta.108, services/server/src/features/authorizations/approval-service.ts:216-224 calls relay.supportsContracts(selected.connector_id, ...) and maps any false to the update-required message. services/server/src/relay.ts:512-520 implements that as a lookup in this instance's in-memory connectors map, requiring a ready open socket. Production is configured with two web instances (mdbase-cloud-ops/render.yaml, numInstances: 2). The distributed relay broker handles remote commands, but this admission check is not broker-aware. An approval HTTP request handled by the non-owning instance can therefore reject a compatible, ready connector; a temporarily unready session yields the same message.

The code establishes a cross-instance false-negative path and misleading error classification. It does not yet prove which condition caused this specific HTTP 400. Production policy-delivery diagnostics are aggregate and were not attributable to this connector. Please correlate the failed approval with the connector's owner instance, readiness, advertised contract support, requested contract requirements, and relay generation before deciding the incident's proximate cause.

Expected / fix criteria

• Approval of a compatible local collection should not depend on which web instance receives the HTTP request.
• Determine compatibility and readiness from the owning relay session (or a suitably fenced distributed authority), preserving exact contract checks, generation fencing, and grant-origin validation. Do not simply bypass supportsContracts or retry until a random instance accepts.
• Report a true version/capability mismatch separately from relay unavailable/not-ready and an expired request.
• Add a two-instance regression: socket and ready compatible session on A, approval on B; also test disconnect/replacement and incompatible support to avoid stale-authority grants.

Related: #427 reports the same user-facing message on beta.99/TaskNotes but does not establish a root cause. This report isolates the beta.108 local-vs-hosted case and the cross-instance code path.