fix(cli): reject an unusable linked service image tag

[avallete]

Summary

TL;DR: supabase link always prefixed Storage and PostgREST versions with v. A body that already started with v was saved as vv…, and startup then tried to pull that unpublished tag. New pins keep a single leading v. An already saved pin that is not a usable image tag, including vv…, now fails and is left on disk.

Before

flowchart LR
  probe["version body<br/>v1.77.1-versions"] --> prefix["always prefix v"]
  prefix --> pin["saved pin<br/>vv1.77.1-versions"]
  pin --> pull["pull unpublished tag"]

Loading

After

flowchart LR
  probe["Storage or PostgREST body"] --> tag["tagForServiceVersion"]
  tag --> pin["one leading v"]
  saved["saved pin"] --> check{"usable tag?"}
  check -->|yes| use["use pin"]
  check -->|no, including vv| err["error, file unchanged"]

Loading

Why

Storage's /version route returns its VERSION string as-is. A normal image is a bare semver such as 1.77.1, and the published tag is v1.77.1, so the CLI prefix is what turns the body into the tag. Some responses already include the prefix, including a suffix such as v1.77.1-versions. Prefixing those saved vv1.77.1-versions. That string was used as the storage-api tag, which is not published, so the pull failed. PostgREST's link pin had the same always-prefix behavior.

Existing vv… files are not rewritten. The next read fails and tells you to run supabase link again.

What changed

• Storage and PostgREST link pins use tagForServiceVersion: a bare semver gains v, and a body that already starts with v is kept, including a suffix.
• Reading a saved service pin that is not a usable image tag fails with InvalidServiceVersionTagError. The file is not changed.
• Empty and missing pin files stay non-fatal.

Linked issue

None.

[github-actions]

🤖 AI Review

The PR fixes newly written Storage pins when the version response already starts with v. Review of the PR code confirms three follow-ups: the link path can still double-prefix PostgREST versions, previously saved vv… Storage pins remain unchanged, and the changed normalization paths in the shared service probes lack tests. Codex reported no additional findings.

Findings

Severity	Location	Category	Sources	Claim
🟠 MAJOR	apps/cli/src/command-internal/tenant-versions.ts:57	backward-compatibility	claude	Previously saved vv… Storage pins are not repaired by this change, so affected projects continue to resolve an invalid Storage image tag until the pin is replaced.
🟡 MINOR	apps/cli/src/shared/services/services.shared.ts:383	test-coverage	claude	The shared PostgREST and Storage probes have no test for the changed already-prefixed or uppercase V normalization behavior.
🟡 MINOR	apps/cli/src/command-internal/tenant-versions.ts:36	correctness	claude	A PostgREST info.version that already starts with v becomes a vv… rest pin during supabase link.

Findings outside the diff

• 🟡 MINOR apps/cli/src/command-internal/tenant-versions.ts:36 — A PostgREST info.version that already starts with v becomes a vv… rest pin during supabase link.

Stats

Claude findings: 3 · Codex findings: 0 · Confirmed: 3 · Refuted: 0 · Uncertain: 0

---

Models: claude-opus-5-5 + gpt-6-sol · Trigger: auto · Workflow run

This review runs once per PR. A maintainer can request another with a /ai-review comment.