Skip to content

Audit @objectstack/client against the dispatcher: whole route domains have no SDK expression (root cause class of #3528) #3563

Description

@os-zhuang

Why

#3528 ("screen-flow Submit never calls resume") was reported as a Console bug. The Console turned out to be mostly fine — but the reporter's own note pinned the real root cause:

@objectstack/client's automation surface exposes getFlow, execute, listRuns, getRun — but no resume. That looks like the root cause: the SDK the Console builds on has no way to express the call.

That was exactly right, and it stranded a real consumer: the Developer → Flow Runs test-runner could trigger a screen flow but had no way to finish it, leaving orphan paused runs behind. Fixed in #3552 by adding automation.resume() / getScreen().

The point of this issue is that the fix was one instance of a class. A route can exist, work, be documented, and still be unreachable from the SDK every consumer builds on — and nothing catches it.

The gap is not small

The dispatcher has 18 domain handlers (packages/runtime/src/http-dispatcher.ts):

handleAI          handleActions     handleAnalytics   handleApiEndpoint
handleAuth        handleAutomation  handleData        handleGraphQL
handleKeys        handleMcp         handleMcpSkill    handleMetadata
handleNotification handlePackages   handleSecurity    handleShareLinks
handleStorage     handleUi

Grepping packages/client/src/index.ts for the corresponding surfaces, several domains appear to have zero SDK expression — no method, no URL string, nothing:

Domain Occurrences in the client
share-links 0
keys (API keys) 0
mcp / mcp-skill 0
security 0

(Rough grep, not a verdict — confirming these is step 1 of the work, and a couple may be intentionally server-only.)

Worth noting alongside: the resume and screen routes had no tests at all before #3552 — the dispatcher tests added there were the first. "Route exists, no SDK method, no test" showed up as a cluster, which suggests looking for that combination rather than only for missing methods.

Proposed work

  1. Enumerate dispatcher routes per domain (method + path + shape) and diff against the client surface. Mechanical and scriptable — api-surface.json may already carry enough to automate it.
  2. Triage the diff into: should be in the SDK / deliberately server-only (document why) / dead route.
  3. Close the "should be" gaps, each with a dispatcher test if one is missing.
  4. Consider a CI guard so the diff can't silently regrow — a checked-in ledger of intentionally-unexposed routes, failing when an unlisted route has no SDK method, would make the next resume impossible to ship unnoticed.

Acceptance

  • A written inventory of dispatcher routes vs SDK coverage, with every gap classified.
  • Gaps in the "should be exposed" bucket either closed or filed with rationale.
  • A guard that fails when a new route lands with neither SDK expression nor an explicit exemption.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions