[nuriyoo]

Closes #918. It is stacked on Fireflies' headers and budget, which is #1062. A root field's argument graphql-js refuses is answered ahead of every resolver's error, as api.linear.app answers it, and one at a non-null field is answered alone, with the data null.

What changed

The engine (backlot/graphql/engine.py). Before it runs an operation, Engine.run asks _refused_root_arguments which root fields' arguments graphql-js would refuse as it starts each field, in the order the fields come, up to the first non-null one. Where there is a non-null one, those errors are the answer, with the data null, and the router writes each as Linear's Internal server error; otherwise the run answers, those errors ahead of its own and in place of its errors at the same fields. On Fireflies, whose root fields are each nullable, the run always answers.

Tests. Twelve rows in _LINEAR_BODIES (tests/test_linear.py) hold a refused argument alone or beside other root fields, viewer, a fragment, a served __type and a refused one among them, and an argument read from its variable's default, each answered as real answered it with the key. Without one each is Linear's 401, as test_linear_orders_the_body_and_the_credential sends a WithTheKey row with each other credential. In tests/test_graphql.py, test_a_field_error_is_marked_by_who_made_it finds graphql-js's refusal of widget(id: $id) first, ahead of an earlier boom's error.

Not in this PR. Which of a by-id root's not-found and a later root field's own refused arguments (sort with orderBy, first with last) Linear answers is #1067.

Why this is what the real API does

Measured. api.linear.app with a personal API key on 2026-10-21, 2026-10-26 and 2026-10-29 (UTC), each request with its own cache-buster, $x sent as null where the row names it:

query                                                                   real
query($x: String = "a") { a: issue(id: "00000000-…") { id }             Internal server error at ["b"], column 100,
  b: issue(id: $x) { id } }                                               data null, no error at ["a"]
the same with b first                                                   the same at ["b"], column 40
query($x: String = "a") { v: viewer { id } b: issue(id: $x) { id } }    the same at ["b"], column 57, viewer's data gone
… a: issue(…) { id } ...F } fragment F on Query { b: issue(id: $x) }    the same at ["b"], column 129
query($x: String = "00000000-…") { b: issue(id: $x) { id } }, no        Entity not found: Issue at ["b"], the default read
  variables
2026-10-26: … t: __type(name: $y) { name } b: issue(id: $x) { id }      Internal server error at ["t"], then at ["b"],
  with both sent null                                                     data null
a: issue(…) b: issue(id: $x) c: team(id: $x), $x null                   the same at ["b"] alone
2026-10-29: query($y: String = "Issue") { a: issue(id: "00000000-…")     Internal server error at ["t"], column 107, then
  { id } t: __type(name: $y) { name } }, $y null                          Entity not found: Issue at ["a"], data null
… u: __type(name: $z) after t, $z null too                              the same at ["t"], then at ["u"], then ["a"]
… s: __type(name: "Team") { name } between a and t                      the same at ["t"], then ["a"]
query($y: String = "Issue") { t: __type(name: $y) { name } }, $y null   Internal server error at ["t"], column 47,
                                                                          data {"t": null}

graphql-js starts each root field in order and Linear's resolvers answer asynchronously, so a refused argument at a later field is thrown before an earlier field's resolver answers; a refusal at a non-null root field, as each of Linear's but __type is, nulls the data, and one at __type leaves the run to answer behind it. Backlot's resolvers answer synchronously, and the check before the run restores graphql-js's order. Each of the twelve rows' bodies is the one real answered, byte for byte.

Verification

• Tests — pytest on uv sync --all-extras --locked plus uv pip install --no-deps "llama-index-readers-hubspot<0.6", as CI installs: 8941 passed, 1 skipped.
• Optional surfaces that ran rather than skipped — every one but the Atlassian MCP test in tests/test_mcp.py, which needs Docker's Linux containers and found no daemon here.
• Lint — ruff check . && ruff format --check .: clean.

At f39a1314, on fireflies-each-answer-carries-fireflies-headers-and-budget at 998147eb.

uv sync --all-extras --locked
uv pip install --no-deps "llama-index-readers-hubspot<0.6"
uv run --no-sync pytest -rs                     8941 passed, 1 skipped in 49.48s
ruff check . && ruff format --check .           All checks passed! / 195 files already formatted
python scripts/prose_check.py <the base>        exit 0
mutations of each line this branch adds         45 (6 by hand), 37 caught
each row against the mutation written for it    24 of 24 rows lose to one; 0 missed

Each line this branch adds was mutated against each test file it or its base changes, and more by hand on the order of the errors, the data a refused non-null field leaves, a refusal's path and nodes, the variables the walk reads and what it takes __type for. The eight survivors cannot change an answer. None for [] or False in what _refused_root_arguments returns reads alike, and if argued as if True leaves the run's errors as they were. Each error the run makes at a root field has a path, and it makes one at each field whose refusal is answered. Validation refuses __type on another root before the walk, and located_error keeps the node get_argument_values gave a refusal.

• A test fails without this change — test_linear_orders_the_body_and_the_credential, test_a_field_error_is_marked_by_who_made_it.
• A new endpoint serving corpus content is ACL-scoped, proved for both an admin and a scoped token — no new endpoint or way in; the check refuses before any resolver reads the store.
• Comments state what was measured, not the history of the fix

[khj809]

Re-checked at f39a1314: every finding of the earlier review is addressed. The refused nullable __type after an unknown issue, alone, and with a served __type between them each answer as api.linear.app does on 2026-10-30, errors, locations and data alike.