Repository navigation
Route parity: discovery-advertised routes must be reachable on the hono server (os serve/dev) — declared === enforced #3369
Description
Activity
- added 4 commits that reference this issue
on Jul 21, 2026 Resolved — closing.
All three asks are satisfied on
main:- e2e gate (ask 2): landed in test(route-parity): declared===enforced gate + honest standalone hono discovery (#3369) #3386 —
packages/runtime/src/route-parity.integration.test.ts. Boots the real hono app the wayos servemounts it (hono server + dispatcher plugin, services provisioned), reads/api/v1/discovery, and asserts every advertised / dispatcher-registered route is reachable (never 404/405/501) for both an anonymous and an admin principal, and that discovery is service-aware in both directions (no dead advertisement). Currently 7/7 green. - fix the two known instances (ask 3): v16.0: per-request admin-gated Server-Timing never emits on the hono server (os serve/dev) #3361 (admin-gated Server-Timing) fixed in fix(server-timing): emit admin-gated per-request Server-Timing on the standard server (#3361) #3384; v16.0: mark-notification-read 404s on os dev/serve — unread never clears (#3354 not effective on hono server) #3362 (notifications mark-read) fixed in fix(i18n/notifications): localize collab notification titles + storage objects; wire the notifications REST routes #3354 with the e2e regression in test(runtime): e2e regression for notifications mark-read on the hono server (#3362) #3388. Both issues closed. The MCP
501is covered by the gate. - reconcile the two registration paths (ask 1):
os servealready mounts both the hono server and the dispatcher (the dispatcher registers its routes on the honohttp.server), so "a route registered once is served by the real entrypoint" holds under the real mount — and the gate now guards that seam against regression. The one deliberate non-change: trimming the standaloneHonoServerPlugindiscovery to only its mounted routes was dropped, because that is a shadowed fallback path (never served under realos serve) and narrowing it would break the cross-package discovery contract@objectstack/clientdepends on (client.hono.test.tsexpectsmetadataadvertised). Can be revisited deliberately if we ever want to collapse the two paths into one.
Refs: #3386, #3384, #3354, #3388, #3361, #3362, #2698, #3358.
- e2e gate (ask 2): landed in test(route-parity): declared===enforced gate + honest standalone hono discovery (#3369) #3386 —
- added a commit that references this issue
on Jul 30, 2026
Problem
Two v16.0 regressions found in the #3358 sweep — #3361 (per-request admin-gated
Server-Timing) and #3362 (mark-notification-read) — share one root cause: the handler is registered on the runtimeHttpDispatcher/createDispatcherPluginpath, butos serve/os dev/os startactually run the hono server (@objectstack/plugin-hono-server), which resolves identity via its own self-containedresolveCtxand mounts only a subset of routes. Handlers on the dispatcher path silently 404 / no-op on the shipped server, even though discovery advertises them (hono-plugin.ts:688advertisesnotifications:→ 404)./api/v1/mcpreturns501from the same block (dispatcher-plugin.ts:660). This is adeclared ≠ enforcedgap for HTTP routes.Because unit tests exercise the two registration paths in isolation (e.g.
server-timing.test.tscallsallowPerfDisclosure()manually "as the dispatcher would"), the integration gap is invisible.Ask — make route reachability
declared === enforced/api/v1/*routes are hono-native vs dispatcher-only, and reconcile the two registration paths so a route registered once is served by the actualos serveentrypoint (or the hono server delegates the dispatcher's routes, as it does for/data).os servemounts it) and asserts every route advertised in/api/v1/discovery(and every dispatcher-registered route) responds — not 404 — for both an anonymous and an admin principal. This gate would have caught v16.0: per-request admin-gated Server-Timing never emits on the hono server (os serve/dev) #3361, v16.0: mark-notification-read 404s on os dev/serve — unread never clears (#3354 not effective on hono server) #3362, and the MCP501./notifications+/notifications/read[/all]) as part of, or ahead of, the reconciliation.Why
A metadata/discovery-driven platform must not advertise routes that 404 on its own default server. One reconciliation + one boot-the-real-server test closes an entire class of "works in the dispatcher, dead on
os serve" bugs.Refs: #3358 (sweep), #3361, #3362. Also surfaced in objectstack-ai/objectui#2762.