CortexDB 0.12.8 — what went wrong for each tenant, and what each one stores

0.12.8 is 0.12.7 plus outcome counters per tenant and an opt-in storage figure in the operator's usage listing, for the hosted admin. Upgrading from 0.12.7 is a drop-in replacement: the new counters are new fields in the existing usage rows (old rows read back as zeros), and nothing about requests or responses changes.

New

• Outcomes per tenant. The IR12 activity counters (GET /v1/usage activity and GET /v1/admin/usage/subtrees) now count how each request charged to a tenant ended: errors_5xx, errors_4xx (the tenant's own bad requests, never 401 or 403), refused_plan (402 PLAN_LIMIT_REACHED) and refused_rate (429 SUBTREE_RATE_LIMITED), each with a _month twin, plus last_error_at and last_error_code. A request reaches its tenant at its plan check or its subtree rate limit (the memory routes); one refused before that counts for none. Each field is left out while 0.
• Storage per subtree on request. GET /v1/admin/usage/subtrees?include_storage=1 adds storage_events, storage_bytes and storage_capped to each subtree (the storage figure of /v1/usage). It walks each subtree's rows (at most 1,000,000 each) on the DB lane, so such a page holds at most 100 subtrees.