Fix .remote Field Stamping in Repo Create

Claude Code·Opus 4.8[1m]·stiak·3mo ago·1hr 48min·3 Checkpoints·4 file changes·+224/-1·37.6K tokens

the "entire repo create" command no longer stamps a usable .remote field: e.g. entire://<cluster>/<path>

3mo ago·4m

API Error: 529 Overloaded. This is a server-side issue, usually temporary — try again in a moment. If it persists, check https://status.claude.com.

I'd like the "entire repo create" command to stamp a usable .remote field: e.g. entire://<cluster>/<path>

3mo ago·12m

Done. entire repo create now stamps a usable remote field in its JSON output.

What changed

cmd/entire/cli/repo.go:

  • repoRemoteURL(r coreapi.Repo) — synthesizes entire://<clusterHost>/<path> from the created repo's resolved coordinates. It does strings.TrimPrefix(path, "/") before joining, so the leading slash the API returns on path (which you flagged) produces a single separator — e.g. path: "/acme/web" → entire://aws-us-east-2.entire.io/acme/web, not a doubled //. Returns "" (field omitted) when either clusterHost or path is still unresolved on a provisioning repo, so we never emit a half-formed URL.
  • repoCreateOutput(*coreapi.Repo) — merges that remote into the repo's JSON. coreapi.Repo has a custom ogen marshaler plus AdditionalProps, so a wrapper struct that embeds it would have its added field shadowed by the promoted MarshalJSON. Instead it round-trips the repo through its own encoder into a map[string]json.RawMessage and injects remote — preserving every original field.
  • The create RunE now calls CreateRepo then repoCreateOutput. Output stays JSON-only (per your choice); repo get/repo list are untouched.

The URL shape matches what git-remote-entire consumes (repoSlug := parsedURL.Path) and mirrors the existing repo mirror synthesis pattern.

Verification

  • mise run fmt — clean
  • mise run lint — 0 issues
  • New tests in cmd/entire/cli/repo_test.go pass: leading-slash dedup, missing/blank coordinates → omitted, and a full round-trip asserting remote is stamped while id/name survive.

jq -r .remote on the create output now yields entire://<cluster>/<path>.

One thing worth confirming when you next hit the real API: that CreateRepo's response actually populates path and clusterHost synchronously (vs. only after provisioning completes). If a fresh create returns them empty, the remote field will be omitted by design — and we'd want to either resolve them another way or document that repo get is where the remote appears once provisioned. Want me to extend the stamping to repo get as a fallback for that case?

commit

3mo ago·9.5s

On main, so I'll branch first, then commit.

You're on a branch

3mo ago·27.1s

Committed on return-remote-from-create as db50a2171:

  • cmd/entire/cli/repo.go — repoRemoteURL + repoCreateOutput, wired into the create command
  • cmd/entire/cli/repo_test.go — unit tests (leading-slash dedup, missing-coordinate omission, full round-trip)

fmt and lint were already clean and the new tests pass. Nothing pushed.

Cursor says: repoCreateOutput unconditionally overwrites the "remote" key in the marshaled object. If the API later adds a first-class "remote" field (or returns it via additional properties), this would silently replace the server-provided value. Prefer only stamping the synthesized field when it isn't already present.

3mo ago·2m

Addressed Cursor's feedback and amended the commit (7de7dce99).

Change in repoCreateOutput: it now only stamps the synthesized remote when the marshaled object doesn't already contain that key — so a future first-class remote field, or one arriving via additional properties, takes precedence over synthesis. Added TestRepoCreateOutput_PreservesServerProvidedRemote to lock in that the server value wins. fmt, lint (0 issues), and all four tests pass.

7de7dcerepo create: stamp a usable entire:// remote in the JSON output `entire repo create` echoed the raw Repo wire JSON, which has clusterHost and path but no ready-to-use clone/remote URL. Synthesize a `remote` field of the form entire://<clusterHost>/<path> (the form git clone and git-remote-entire accept), merged into the create output. The path the API returns carries a leading slash, so trim it before joining to avoid a doubled separator. Omit the field entirely when either coordinate is unresolved (e.g. a still-provisioning repo) rather than emit a half-formed URL. The synthesis only fills a gap: if the wire object already carries a `remote` (a future first-class field, or one arriving via additional properties) it's left untouched so the server value wins. Repo carries a custom marshaler plus additional properties, so the repo is round-tripped through its own encoder and the remote merged in rather than embedded in a wrapper struct. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Entire-Checkpoint: 4e76f426e952+210/-1

What do you think of this feedback: "repoCreateOutput dereferences r (via *r) without guarding against a nil pointer; if a caller ever passes a nil repo (e.g., unexpected API behavior), this will panic rather than returning an error."

3mo ago·2m

Committed as cce6f8300.

Summary of what this addresses: added a nil guard at the top of repoCreateOutput (returning an error instead of panicking) plus TestRepoCreateOutput_NilRepoErrors. While wiring it up I also caught that the errors.New swap had left the errors import missing — the build was broken — so I added the import. Build, tests, and lint (0 issues) are all green.

The nil case stays defensive rather than reachable in practice (the caller only passes a repo on a nil-error create), but the helper now enforces its own contract.

cce6f83repo create: guard repoCreateOutput against a nil repo repoCreateOutput dereferenced its *Repo argument (via *r in the remote synthesis) without a nil check. The sole caller only passes a repo after a nil-error create, so this defends the contract rather than a live path — but a nil pointer would slip past json.Marshal (which encodes a nil pointer as "null" without error) and panic later on the dereference. Return an error up front instead. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Entire-Checkpoint: fade5f8ccb64+14