• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

supabase / cli / 29006735530
65%
develop: 65%

Build:
Build:
LAST BUILD BRANCH: gh-readonly-queue/develop/pr-5871-79379d9a68740d939ab131ccb3fca28a80d600e7
DEFAULT BRANCH: develop
Ran 09 Jul 2026 09:03AM UTC
Jobs 1
Files 229
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

09 Jul 2026 09:01AM UTC coverage: 65.08%. Remained the same
29006735530

push

github

web-flow
fix(cli): remove doubled "Expected: Expected" prefix from Flag.choice/primitive errors (#5831)

## What changed

Any `Flag.choice(...)`/`Flag.choiceWithValue(...)`-backed flag (`--size`
on
`projects create`/`branches create`, `--dns-resolver`,
`--output-format`,
`--output`/`-o`, `--agent`) showed a doubled "Expected: Expected ..."
prefix
when given an invalid value, e.g.:

```
Invalid value for flag --size: "nano". Expected: Expected "micro" | "small" | ... , got "nano"
```

Root cause: several `Primitive`s under `effect@4.0.0-beta.93`'s
`effect/unstable/cli` (`choice` — used by
`Flag.choice`/`Flag.choiceWithValue`
— plus the schema-backed `integer`, `float`, `boolean`, and `date`) fail
with
a raw message that already starts with the word "Expected" (e.g.
`` `Expected ${validChoices}, got ${value}` `` for `choice`, or
`Expected a valid date, got Invalid Date` for `date`), and
`CliError.InvalidValue`'s own `message` getter (`CliError.ts:359-364`)
independently prepends its own `"Expected: "` label on top of that —
producing the doubling for any flag or argument backed by one of these
primitives. This is a bug in the vendored `effect` beta package itself,
not
in this repo's code.

Workaround (until upstream `effect` is fixed) added to the shared CLI
error-formatting layer (`subcommand-flag-suggestions.ts`), which already
carries similar per-tag rewrites for
`UnrecognizedOption`/`UnknownSubcommand`:
collapse the literal `"Expected: Expected "` substring down to a single
`"Expected "` whenever it appears in an `InvalidValue` error's rendered
message. Collapsing the exact doubled substring (rather than rebuilding
the
surrounding "Invalid value for ..." template ourselves) keeps the fix
tied
to the precise defect, covers every affected primitive uniformly, and
lets
every other part of the message keep tracking upstream's own wording if
it
changes.

Verified against `go-parity-auditor`: Go's real CLI shows a completely
different message for the same scenario... (continued)

11145 of 17125 relevant lines covered (65.08%)

10.49 hits per line

Coverage Regressions

Lines Coverage ∆ File
2
82.41
0.0% internal/storage/rm/rm.go
Jobs
ID Job ID Ran Files Coverage
1 29006735530.1 09 Jul 2026 09:03AM UTC 229
65.08
GitHub Action Run
Source Files on build 29006735530
  • Tree
  • List 229
  • Changed 1
  • Source Changed 0
  • Coverage Changed 1
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Repo
  • Github Actions Build #29006735530
  • 425be7db on github
  • Prev Build on develop (#29001108167)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc