Repository navigation
fix(plugin-hono-server): compute the standalone discovery routes from real registrations (#4018) - #4063
Merged
Conversation
… real registrations (#4018) `registerStandardEndpoints` served a fully STATIC discovery: a hardcoded `routes` table listing auth/packages/analytics/workflow/automation/ai/ notifications/i18n/storage/ui regardless of what the host mounted. A standalone Hono deployment advertised ten route families and 404'd on every one no plugin bridged — the "advertise a route that doesn't exist" class ADR-0076 D12 exists to kill, and why this surface disagreed with the two real discovery builders (`HttpDispatcher.getDiscoveryInfo`, `metadata-protocol`'s `getDiscovery`), which both compute at runtime. Closed on both axes, without adding a third service-registry walk to keep in sync with the other two: - Single owner (D11 / OQ#9): when `@objectstack/rest` or the runtime dispatcher is on the kernel, this surface no longer registers `${prefix}/discovery`. Both register during plugin `start()` — before this `kernel:ready` hook — and Hono is first-registration-wins, so they already shadowed this handler in every composed deployment: the cede changes no served payload, it removes a third one nobody read. `/.well-known/objectstack` is ceded to the dispatcher only, since REST never registers it. - Computed, not hardcoded (D12): when this surface does own `/discovery`, `routes` is derived per request from the app's live Hono route table — a family is advertised iff a route is really registered at or under its base. Per request, because siblings keep mounting through the rest of `kernel:ready`; requiring the base or a `/`-separated child, so a wildcard ABOVE the base (global `/*`, `/api/v1/*`) never counts as a mount. Tests drive the real Hono app rather than a mocked route table: `hono-discovery.test.ts` covers the bare host advertising only what it mounts, late mounts and wildcards, and both cede paths. `client.hono.test.ts` now asserts the honest shape — `routes.metadata` absent on a host where `GET /api/v1/meta/objects` really is 404. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013VZLsKypjrGhiLpio2uWKu
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
Contributor
📓 Docs Drift CheckThis PR changes 2 package(s): 14 hand-written doc(s) reference the affected code and may need an implementation-accuracy re-verification:
|
…scovery-hardcoded-2ysa9f
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
2 participants
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.
Closes #4018。
问题
plugin-hono-server的registerStandardEndpoints便捷面返回一份完全静态的 discovery：routes表硬编码auth/packages/analytics/workflow/automation/ai/notifications/i18n/storage/ui，不看任何东西是否真的挂上。standalone Hono 部署因此宣传十个路由族、而其中没有插件桥接的每一个都 404 —— 正是 ADR-0076 D12 要修掉的那一类，也是它与两个真 discovery 面（dispatcher 的getDiscoveryInfo、protocol 的getDiscovery，两者都按运行时计算）不一致的原因。补充一点 issue 里没提到的：
registerStandardEndpoints的构造函数默认值是true（hono-plugin.ts的constructor），所以"仅显式开启时才有"这个缓解因素比记录的要弱——任何直接new HonoServerPlugin()的嵌入方都拿到了这张静态表。改法
采用 issue 建议里倾向的方向（退役这份重复供给），但保留 bare-standalone 这唯一真正需要它的形态；没有引入第三份需要长期同步的 discovery 逻辑：
@objectstack/rest或 runtime dispatcher 时，本面不再注册${prefix}/discovery。两者都在插件start()期间注册，早于本处的kernel:readyhook，而 Hono 是先注册先赢——也就是说它们在任何组合部署里本来就已经遮蔽了这个 handler。所以 cede 不改变任何客户端看到的 payload，只是不再产出第三份没人读的表。/.well-known/objectstack只让给 dispatcher（REST 从不注册它），这样 REST-without-dispatcher 的组合仍保留这个跳转。/discovery时，routes改为每次请求从 app 的实时 Hono 路由表推导——某个族被宣传，当且仅当确实有路由注册在它的 base 上或其下。之所以按请求算：兄弟插件在kernel:ready余下的过程里还会继续挂路由，注册时刻拍的快照会漏掉；要求命中 base 本身或/分隔的子路径，则挂在 base 之上的通配（全局/*、/api/v1/*）不会被误判成一次挂载。选"按注册"而不是照抄
hasXxx的"按服务"：在这个面上服务注册并不蕴含路由挂载（把服务桥接到 HTTP 的正是 dispatcher，而这里没有它），所以"注册了什么路由"才是更严格、也更诚实的那个问题。验证
测试直接驱动插件构建的真实 Hono app，而不是 mock 一张路由表：
hono-discovery.test.ts（10 例）：bare host 只宣传自己挂的（data+/auth/me/*两个 helper，其余十族全部缺席）、被通配挂载的族会出现、discovery 接好之后才落地的挂载也能反映、base 之上的通配不算数、realtime永不宣传、transactionalBatch: false保持（discovery 广播「跨对象原子 batch」能力位(让客户端声明式协商,取代 404/405/501 运行时探测) #3298），以及两条 cede 路径。client.hono.test.ts改为断言诚实形态：该 boot 上routes.metadata缺席，并同时断言GET /api/v1/meta/objects真的是 404（证明这个缺席是诚实的，不是漏报）。跑过并全绿：
plugin-hono-server全量client全量runtime：dispatcher-plugin.ready/route-parity/notifications.hono集成qa/http-conformance全量tsc --noEmit+eslintroute-parity的组合 boot 日志里能看到 cede 生效：行为变化
standalone
HonoServerPlugin（无 REST、无 dispatcher）上，GET /api/v1/discovery不再列出没人挂的族——最显眼的是routes.metadata（/api/v1/meta随@objectstack/rest/dispatcher 出货）。@objectstack/client对缺失的 key 会回落到约定路径，connect()不受影响。组合部署（os serve、cloud）零变化：那里服务的一直是 dispatcher 的 service-aware discovery。已在 ADR-0076 D12 追加一条
(Update #4018: …)，把这第三个 publisher 的收口记进 D12 残留盘点。Generated by Claude Code