The job HTTP surface fails with bare http.Error, so none of its refusals reach telemetry #383

New issue

Closed

opened 2026-08-13 11:33:50 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-13 11:33:50 +00:00

Member

The gap I named and deliberately left open when closing #351. Picking it up rather than leaving it as a comment on a closed issue.

What is missing

Every failure path in internal/community/jobhttp.go uses bare http.Error. The turn endpoint routes its failures through writeHTTPError, which emits an exception event, sets span attributes, and records the outcome. Job submission, polling, and cancellation record nothing at all.

Six paths, no telemetry:

Path	Status
jobs not enabled	404
method not allowed	405
malformed body	400
body over the cap	400
job not found, or another principal's	404
queue full	503
submission refused	400

So a caller hammering job submission with bad payloads is invisible, and #159's error-rate split cannot see this surface at all. sirens_echo.failures under-reports by exactly the amount this endpoint fails.

Why it is all of them and not the two I touched

I fixed the oversize message here in 351 and left the telemetry. The tempting scope now is just the two decode paths, because those are the ones I already have my hands on. That would leave four paths dark and two lit, which is the same partial-instrument shape this battery keeps turning up - and worse than uniformly dark, because a metric that covers some of a surface reads as covering all of it.

The cardinality question, which is the real content of this issue

docs/sirens-echo-exceptions.md calls the catalog's size a hard grouping bound and requires an explicit entry plus a reviewed increase. It is at 27 after 351 moved it from 26.

A coherent set for this surface is five codes under a new jobs stage:

job_request_invalid - malformed body
job_body_too_large - the cap, separate for the reason 351 established
job_rejected - submission refused, caller's fault
job_not_found - absent or another principal's, which are deliberately indistinguishable
job_queue_full - service condition, not the caller's fault

That takes the bound 27 to 32. Method-not-allowed and jobs-not-enabled reuse nothing and get nothing, because both are answerable from the route alone and neither is a failure worth grouping.

Five at once is a larger increase than I have taken unilaterally before. The pull request is the review the document asks for, and if 32 is too many the answer is to fold job_queue_full into job_rejected and lose the caller-versus-service split, which I would rather not do since that split is exactly what 159 needs.

Acceptance

Every failure path above records an exception and an outcome.
The caller-versus-service fault is set correctly on each, so 159 can bucket them.
No response body gains detail it did not have, since the messages are already right.
The bound moves deliberately, with the doc updated in the same commit.

CLAIM - Angie (ENG, claude seat) 2026-08-13T11:35Z, 20 min.

The gap I named and deliberately left open when closing https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/351. Picking it up rather than leaving it as a comment on a closed issue. ## What is missing Every failure path in `internal/community/jobhttp.go` uses bare `http.Error`. The turn endpoint routes its failures through `writeHTTPError`, which emits an exception event, sets span attributes, and records the outcome. Job submission, polling, and cancellation record nothing at all. Six paths, no telemetry: | Path | Status | | --- | --- | | jobs not enabled | 404 | | method not allowed | 405 | | malformed body | 400 | | body over the cap | 400 | | job not found, or another principal's | 404 | | queue full | 503 | | submission refused | 400 | So a caller hammering job submission with bad payloads is invisible, and https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/159's error-rate split cannot see this surface at all. `sirens_echo.failures` under-reports by exactly the amount this endpoint fails. ## Why it is all of them and not the two I touched I fixed the oversize message here in 351 and left the telemetry. The tempting scope now is just the two decode paths, because those are the ones I already have my hands on. That would leave four paths dark and two lit, which is the same partial-instrument shape this battery keeps turning up - and worse than uniformly dark, because a metric that covers some of a surface reads as covering all of it. ## The cardinality question, which is the real content of this issue `docs/sirens-echo-exceptions.md` calls the catalog's size a **hard grouping bound** and requires an explicit entry plus a reviewed increase. It is at 27 after 351 moved it from 26. A coherent set for this surface is five codes under a new `jobs` stage: - `job_request_invalid` - malformed body - `job_body_too_large` - the cap, separate for the reason 351 established - `job_rejected` - submission refused, caller's fault - `job_not_found` - absent or another principal's, which are deliberately indistinguishable - `job_queue_full` - service condition, not the caller's fault That takes the bound 27 to 32. Method-not-allowed and jobs-not-enabled reuse nothing and get nothing, because both are answerable from the route alone and neither is a failure worth grouping. **Five at once is a larger increase than I have taken unilaterally before.** The pull request is the review the document asks for, and if 32 is too many the answer is to fold `job_queue_full` into `job_rejected` and lose the caller-versus-service split, which I would rather not do since that split is exactly what 159 needs. ## Acceptance - Every failure path above records an exception and an outcome. - The caller-versus-service `fault` is set correctly on each, so 159 can bucket them. - No response body gains detail it did not have, since the messages are already right. - The bound moves deliberately, with the doc updated in the same commit. **CLAIM - Angie (ENG, claude seat)** 2026-08-13T11:35Z, 20 min.

coilyco-ops referenced this issue from a commit

2026-08-13 11:37:42 +00:00

feat(jobs): every job refusal now records what it refused and whose fault it was

coilyco-ops referenced this issue from a pull request that will close it,

2026-08-13 11:37:43 +00:00

feat(jobs): every job refusal now records what it refused and whose fault it was #384

coilyco-ops closed this issue

2026-08-13 11:40:35 +00:00

coilyco-ops referenced this issue

2026-08-13 11:40:45 +00:00

Two claims are signed with a seat label their author does not hold, and the claim protocol depends on that label #353