Skip to content

fix(cli): narrow axios response headers to string at use sites#361

Merged
aaronsb merged 1 commit into
mainfrom
fix/cli-axios-header-typing
May 13, 2026
Merged

fix(cli): narrow axios response headers to string at use sites#361
aaronsb merged 1 commit into
mainfrom
fix/cli-axios-header-typing

Conversation

@aaronsb
Copy link
Copy Markdown
Owner

@aaronsb aaronsb commented May 13, 2026

What

Three call sites in the CLI access response headers with .includes(...) or parseInt(...):

  • cli/src/api/client.ts — Content-Disposition match, Content-Type sniff, Content-Length parse
  • cli/src/cli/config.ts — Content-Type sniff for API discovery
  • cli/src/cli/login.ts — same Content-Type sniff

Axios types response.headers[x] as string | number | true | string[] | AxiosHeaders, but HTTP responses always return strings. The broader union breaks type-checking. Cast to string | undefined at each boundary.

Why now

Pre-existing TypeScript Build Check failure on main (seen on PR #360 V2 merge). Unblocks CI for the upcoming exploration-action-layer refactor PR.

Risk

Zero behavioral change — all sites already assumed string semantics at runtime.

Axios types response `headers[x]` as the union `string | number | true | string[] | AxiosHeaders`, but actual HTTP responses always return strings. Three call sites called `.includes(...)` or passed the value to `parseInt`, which fails type-checking under the broader union. Cast to `string | undefined` at each boundary.

Pre-existing failure in TypeScript Build Check, unblocks CI for downstream PRs (action-layer refactor).
@aaronsb aaronsb merged commit 7c75778 into main May 13, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant