You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(deploy): validate deployment id as 8-hex app_id, not UUID (#43)
The six deployment-by-id tools (get_deployment, get_deployment_events,
redeploy, delete_deployment, update_deploy_env, wake_deployment) applied
uuidSchema (canonical 8-4-4-4-12) to their `id` arg. But a deployment's
public id (app_id/token, returned as `deploy_id` by create_deploy) is
8-char lowercase hex — the api's generateAppID() is hex.EncodeToString of
4 random bytes (api/internal/handlers/deploy.go). zod therefore rejected
EVERY real call client-side (-32602) before it reached the api, killing
the entire manage-the-deploy loop through MCP.
Introduce deployIdSchema (/^[0-9a-f]{8}$/) and apply it to exactly those
six tools; resource-token tools keep uuidSchema (their tokens ARE UUIDs).
Why it shipped green: (a) test/mock-api.ts was edited to EMIT UUID-shaped
app_ids "like prod" — but prod does not, so fixtures never tripped the bad
schema; (b) the handler tests call .handler directly, bypassing the zod
inputSchema the real SDK dispatch applies. Revert the mock to emit 8-hex
app_ids and add a regression test that drives the registered inputSchema
(the dispatch path) for all six tools, iterating the registry (rule 18).
Also pin zod in dependencies (was an implicit SDK peer).
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
0 commit comments