The production canary service is not answering a tenant correctly. Failing stage: 2/4 logs (bex-api does not report the request it just served) (exit 4).
Probe output:
== w3/m83 tenant-view canary: srv-daif6dsmg29s73d1umvg ==
==> 1/4 wake: request the public host (budget 60s)
ok: 200 in 0s (nonce recorded, not a secret: tvl1790807719fbb10b528d3c)
==> 2/4 logs: bex-api must return this run's request line and the app stream (budget 180s)
FAIL(2/4 logs): after 180s bex-api still does not report this service's own traffic.
type=request line for this run: found1
type=app lines for this service: MISSING
The request DID reach the service (stage 1 got 200), so this is a
read-path failure, not a quiet service — the w6/m131 (shipper
attribution) or w6/m110 (bex-api queries the wrong selector) class.
Compare with scripts/request-logs-liveness.sh: if that is green and
this is red, the shipper is fine and the API's query is wrong.
Read the stage before the pipeline: stage 1 red is a hosting/activator failure, stages 2-4 red with stage 1 green mean the service IS serving and bex-api is answering wrongly — the w6/m110 class, where the series exist and the query names them wrong. Cross-check request-logs-liveness in this same workflow: green there plus red here isolates the fault to bex-api's query rather than the shipper.
The production canary service is not answering a tenant correctly. Failing stage: 2/4 logs (bex-api does not report the request it just served) (exit 4).
Probe output:
Read the stage before the pipeline: stage 1 red is a hosting/activator failure, stages 2-4 red with stage 1 green mean the service IS serving and bex-api is answering wrongly — the w6/m110 class, where the series exist and the query names them wrong. Cross-check
request-logs-livenessin this same workflow: green there plus red here isolates the fault to bex-api's query rather than the shipper.