Several upstream API endpoints return HTTP 200 with an HTML error page

[timrabl]

Observed against the live API on 2026-07-20. Four endpoints return HTTP 200 with Content-Type: text/html and a server-side error in the body:

Endpoint	Body
/api/speed	Table 'fixedspeed' doesn't exist in database when dumping meta-data for Application\Models\Fixedspeed
/api/speed/{id}	SQLSTATE[42000]: Syntax error or access violation: 1055 Expression #1 of SELECT list is not in GROUP BY clause...
/api/provider/{id}	HTML
/api/statistics	HTML

Still working: /api/provider (list) and /api/plans_desktop/{id}.

Not our bug — filed for the record, because it makes bbmctl list speeds, provider show (remote lookup), and statistics unusable until upstream fixes it.

The library handles these correctly: the content-type check produces a clear error rather than a deserialisation failure. Note the 200-byte preview in that error path is exactly the code that panicked on multi-byte characters before #24.

The three #[ignore]d tests covering these endpoints now fail when run with --ignored. Worth deciding whether they should assert graceful degradation instead of a successful response.

[timrabl]

Status 2026-07-21: still broken upstream. /api/provider (list) and /api/plans_desktop/{id} work; /api/provider/{id}, /api/speed, /api/speed/{id}, and /api/statistics all return HTTP 200 with an HTML error page (Table 'fixedspeed' doesn't exist, Unknown column 'fixedoperator.topten', various SQLSTATE errors).

Nothing to fix on our side — the library already degrades gracefully (a non-JSON body becomes a clean BbmError::Api, never a panic or deserialize error). #47 hardened the ignored live-API tests to assert that contract, so cargo test -- --ignored now passes even while upstream is down instead of panicking.

Keeping this open purely to track the upstream outage. Re-check periodically; close when the endpoints recover.