Doist / Doist/comms-cli

Bare opaque ids without a digit are rejected, and bad ids surface as raw SDK errors

Open
#65 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
0
Forks
0
Avg merge
6h 35m
Merged PRs (30d)
10

Description

Two small things I ran into while working on #64, both reproduced on 3.4.0 (aa8e93a). Neither is a regression from that PR.

Bare opaque ids are rejected when they contain no digit

tdc conversation done CDMDzXhBNCgyQZjkDnqwG --dry-run
# Error: INVALID_REF
# Invalid conversation reference: CDMDzXhBNCgyQZjkDnqwG. Use an id, id:<id>, or a Comms URL.

tdc conversation done id:CDMDzXhBNCgyQZjkDnqwG --dry-run
# [dry-run] Would archive conversation: ...

Expected: the bare form works, like tdc thread view Cf9TR6CPC2dKQL5fB2EoL does.

It's not conversation-specific; the three resolvers in refs.ts are identical. parseRef only treats a bare token as an id when looksLikeRawId passes (refs.ts:68, 151), and that requires at least one digit. The fallback looksLikeOpaqueCommsId (refs.ts:75) only accepts a Cb prefix. This id has no digit and starts with CD, so it's parsed as a name. Swap any letter for a digit, or the prefix for Cb, and the same command reaches the API. Base58 has 9 digits in 58 characters, so a 21-character id comes out digit-free about 3% of the time ((49/58)^21), roughly one id in thirty.

A malformed or missing id surfaces as a raw SDK error

tdc thread view id:nope
# CommsRequestError: Request failed with status 409
#     at fetchWithRetry (.../comms-sdk/dist/esm/transport/fetch-with-retry.js:28:23)
#     ...

tdc thread view Cf9TR6CPC2dKQL5fB2EoL --comment id:nope     # same
tdc thread view id:nope --json
# {"error":{"code":"INTERNAL_ERROR","message":"Request failed with status 409"}}

Expected: a CliError (NOT_FOUND or INVALID_REF) with a hint, per AGENTS.md.

The 409 is the API's "id must decode to 16 bytes" (error_code 217); a well-formed id that doesn't exist gets a 404 and prints the same stack trace. The catch in api.ts maps 403 (both flavours) and 401 and rethrows everything else (api.ts:192-220), so 404 and 409 fall through to the generic branch in index.ts:230.

Happy to open a PR for either if useful.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the three resolvers and parseRef in src/lib/refs.ts, then inspect the error mapping in src/lib/api.ts and the generic branch in src/index.ts, reproducing the listed commands. Done means digit-free bare opaque IDs resolve like explicit ids, while missing or malformed IDs produce the expected hinted CliError instead of a raw SDK error.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
api, cli
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
76/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.