Repository navigation
feat(cli): show the project ID in sandbox, snapshot and template lists - #2106
mishushakov wants to merge 1 commit into
Conversation
🦋 Changeset detectedLatest commit: fb3ee57 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
PR SummaryLow Risk Overview List helpers take Reviewed by Cursor Bugbot for commit fb3ee57. Bugbot is set up for automated code reviews on this repo. Configure here. |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
There was a problem hiding this comment.
TASTE.md review of #2106 (CLI only, so the SDK parity rules T-1/T-2 don't apply). Checked: naming and abbreviation casing (T-12), absence as undefined (T-20), backend as source of truth (T-52), config through ConnectionConfig (T-49), and docs on new helpers (T-69).
2 violations:
- T-12: the new JSON key is
projectIdon sandboxes and snapshots butprojectIDon templates. It should beprojectIDeverywhere (2 inline comments). - T-52:
publicProjectId()re-implements workspace-api'spublic_idencoding on the client instead of using thepublic_idthe server returns (1 inline comment).
Not tied to a line: the conditional spreads keep the field and column out entirely with E2B_API_KEY instead of emitting null, which complies with T-20. Internal helper names (projectIdOf, publicProjectId) also use Id, which is the existing CLI convention (resolveProjectId), so they're not flagged inline. They can follow whatever you pick for the JSON key.
| JSON.stringify(sortSandboxes(sandboxes, options.order), null, 2) | ||
| JSON.stringify( | ||
| sortSandboxes(sandboxes, options.order).map((sandbox) => | ||
| projectId ? { ...sandbox, projectId } : sandbox |
There was a problem hiding this comment.
T-12 — abbreviations keep their casing in identifiers: ID, not Id. This PR adds the same new JSON key in three places and spells it two ways — projectId here and in sandbox snapshot list, but projectID in template list. So jq '.[].projectID' works on one list and silently returns null on the other two. Use the T-12 spelling, which template list already uses, everywhere. It's a new key, so it doesn't matter that the neighbouring sandboxId predates the rule:
| projectId ? { ...sandbox, projectId } : sandbox | |
| projectId ? { ...sandbox, projectID: projectId } : sandbox |
| console.log( | ||
| JSON.stringify( | ||
| snapshots.map((snapshot) => | ||
| projectId ? { ...snapshot, projectId } : snapshot |
There was a problem hiding this comment.
T-12 — same issue as in sandbox list: the new key should be projectID, matching template list and the ID casing rule:
| projectId ? { ...snapshot, projectId } : snapshot | |
| projectId ? { ...snapshot, projectID: projectId } : snapshot |
| * The `prj_` public ID of a project UUID: the TypeID encoding workspace-api | ||
| * uses for `public_id`, computed locally so lists don't need `/v1/me`. | ||
| * Anything that isn't a UUID is returned as is. | ||
| */ | ||
| export function publicProjectId(id: string): string { | ||
| const hex = id.replace(/-/g, '') | ||
| if (!/^[0-9a-f]{32}$/i.test(hex)) return id |
There was a problem hiding this comment.
T-52 — the backend is the source of truth, and client code must not copy backend business rules ("a duplicated rule drifts from the server's the moment the API changes"). This re-implements workspace-api's public_id TypeID encoding in the CLI, even though the server already returns public_id (see Project.public_id, used by findProject above). If workspace-api changes the prefix, alphabet or ID scheme, the CLI keeps printing well-formed prj_ IDs that match nothing, and no test fails. Only the unit test's single fixture ties the two together.
The fallback makes this worse. Any X-Team-ID that isn't a UUID comes back unchanged and is still shown under the Project ID header.
Compliant form: take public_id from the server. When --project / the saved project is resolved through findProject / fetchMe, keep the matched project.public_id (or cache it next to the selected project in the user config) and pass that through. When the CLI doesn't have the server's value, leave the column out, the same way the E2B_API_KEY case already does, rather than computing it.
Package ArtifactsBuilt from 641db40. Download artifacts from this workflow run. JS SDK ( npm install ./e2b-dockerfile-utils-0.1.2-mishushakov-cli-list-project-ids.0.tgz ./e2b-2.63.1-mishushakov-cli-list-project-ids.0.tgzCLI ( npm install ./e2b-cli-2.23.1-mishushakov-cli-list-project-ids.0.tgzCode Interpreter JS SDK ( npm install ./e2b-code-interpreter-2.9.2-mishushakov-cli-list-project-ids.0.tgzDesktop JS SDK ( npm install ./e2b-desktop-2.5.1-mishushakov-cli-list-project-ids.0.tgzPython SDK ( pip install ./e2b_dockerfile_utils-0.1.1+mishushakov.cli.list.project.ids-py3-none-any.whl ./e2b-2.63.0+mishushakov.cli.list.project.ids-py3-none-any.whlCode Interpreter Python SDK ( pip install ./e2b_code_interpreter-2.11.9+mishushakov.cli.list.project.ids-py3-none-any.whlDesktop Python SDK ( pip install ./e2b_desktop-2.7.2+mishushakov.cli.list.project.ids-py3-none-any.whl |
None of the list responses carry a project: each list is scoped to the project the request went to (X-Team-ID). The lists now show that project's prj_ ID as a `Project ID` column, and as `projectId` (`projectID` for templates, matching `templateID`) in JSON output. The prj_ ID is the TypeID encoding of the project UUID, computed locally (publicProjectId), so lists don't need a /v1/me call. With E2B_API_KEY the key decides the project and the CLI can't tell which, so the column and field are left out. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
fa9c2a9 to
9bcfdbd
Compare
cd6124b to
fb3ee57
Compare
|
Closing: not needed. The list commands stay as they are; |
|
Wanted after all (2026-11-12), but this PR can't be reopened after the rebase: continued in #2124. |
Summary
e2b sandbox list,e2b sandbox snapshot listande2b template listnow show which project they're listing. With--projectavailable on every command (#2105), the output alone didn't tell you which project you were looking at. Stacked on #2105.How
ListedSandbox,Template,SnapshotInfo) carry a team or project field; each list is scoped to the project the request went to viaX-Team-ID. So the ID comes from the request's own auth:projectIdOf(auth)readsX-Team-ID.prj_form, computed locally:publicProjectId()produces the TypeID encoding workspace-api uses forpublic_id(Crockford base32 of the UUID). Lists don't need a/v1/meround trip, and the IDs matche2b project list. It's checked against a real project'sid/public_idpair.Project IDcolumn, added last so the existing column order doesn't change;projectIDon sandboxes, snapshots and templates, so onejqpath works for all three lists.E2B_API_KEYthe key decides the project and the CLI can't tell which, so the column and field are left out rather than showing a guess.Testing
tests/commands/list_project_id.test.ts(4): each list in pretty and JSON with access-token auth, and with an API key (no column, no field). The SDK is mocked.tests/workspaces.test.ts:publicProjectIdon a real UUID/prj_pair, plus pass-through for non-UUIDs.pnpm run testinpackages/cli: 214 passed, 11 skipped. Integration tests skip withoutE2B_API_KEY, andtemplate create's backend suite fails by design without it, as onmain.template list,sandbox snapshot listandsandbox list --project <other project> -f jsonshow the IDs. I couldn't run theE2B_API_KEYcase on prod (no key available locally); the unit test covers it.Part of PRD-119.
🤖 Generated with Claude Code