fj pr checks errors with 'invalid type: null, expected a sequence' when a PR has no checks #241

New issue

Closed

opened 2026-08-08 23:40:32 +00:00 by stephen · 0 comments

stephen commented

2026-08-08 23:40:32 +00:00

Owner

fj pr checks fails to deserialize the response when a PR has no status
contexts, instead of reporting that there are none.

Reproduction

rasterstate/assay-research has no CI configured, so PR #1 reports no statuses:

$ fj pr checks --repo rasterstate/assay-research 1
error: invalid type: null, expected a sequence

The API is returning null rather than [] for the status list, and the
deserializer requires a sequence.

Expected

Something like no checks reported on <sha>, and exit 0. A repo with no CI is a
normal state, not an error, and it is the state every new repo starts in.

Why it matters beyond cosmetics

The message names no repo, no PR, and no field, so it reads like a bug in fj's
own request rather than a description of the PR. When you are checking whether
something is safe to merge, "error" and "there are no checks" call for opposite
decisions, and this conflates them. I hit it while deciding whether a PR was
gated, and had to fall back to fj api .../statuses to establish that the answer
was simply "none".

Suggested fix

Deserialize the status list with a null-tolerant default (#[serde(default)] on
the field, or Option<Vec<_>> unwrapped to empty) and print the empty case
explicitly. Worth a look at whether other list-shaped responses have the same
assumption; null for an empty array is common in this API.

`fj pr checks` fails to deserialize the response when a PR has no status contexts, instead of reporting that there are none. ## Reproduction `rasterstate/assay-research` has no CI configured, so PR #1 reports no statuses: ``` $ fj pr checks --repo rasterstate/assay-research 1 error: invalid type: null, expected a sequence ``` The API is returning `null` rather than `[]` for the status list, and the deserializer requires a sequence. ## Expected Something like `no checks reported on <sha>`, and exit 0. A repo with no CI is a normal state, not an error, and it is the state every new repo starts in. ## Why it matters beyond cosmetics The message names no repo, no PR, and no field, so it reads like a bug in `fj`'s own request rather than a description of the PR. When you are checking whether something is safe to merge, "error" and "there are no checks" call for opposite decisions, and this conflates them. I hit it while deciding whether a PR was gated, and had to fall back to `fj api .../statuses` to establish that the answer was simply "none". ## Suggested fix Deserialize the status list with a null-tolerant default (`#[serde(default)]` on the field, or `Option<Vec<_>>` unwrapped to empty) and print the empty case explicitly. Worth a look at whether other list-shaped responses have the same assumption; `null` for an empty array is common in this API.

stephen added the

label

2026-08-08 23:40:32 +00:00

stephen referenced this issue from a pull request that will close it,

2026-08-09 00:34:22 +00:00

Handle PR checks with no status contexts #242

stephen closed this issue

2026-08-09 00:54:16 +00:00

stephen referenced this issue from a commit

2026-08-09 00:54:17 +00:00

Handle PR checks with no status contexts (#242)

stephen referenced this issue