cc-ci
eb1d6d9161
continuous-integration/drone/push Build is failing
plausible v3 (community-edition) only ingests events for a site that belongs to a TEAM. The custom tier registered a site row and nothing else, which was enough for v2 — under v3 the POST still acks 202 and the row still exists in postgres, but every event is discarded. ClickHouse records the reason itself in ingest_counters as dropped_not_found, and events_v2 stays empty, so it presents as a silent ingestion stall. Verified on cc-ci against v3.2.1: identical site row with no team -> dropped_not_found and 0 rows; with a team linked -> buffered and the rows land. _register_site now provisions a team and links the site, guarded on the schema actually having teams so it stays a no-op on v2 (the upgrade tier deploys the older base first). Separately, the custom health check waited 60s for /api/health. That tier runs after backup/restore, which disrupts postgres under the app and restarts it, and v3 boots through sleep 10 + createdb + migrate + cache warmers before health flips to 200. Widened to 300s, still far inside the recipe HTTP_TIMEOUT of 1200. The assertion is unchanged: a hard 200 from the real readiness endpoint. Neither change weakens a test - the event tests still require the row to arrive in ClickHouse and match what was sent.
29 lines
1.4 KiB
Python
29 lines
1.4 KiB
Python
"""plausible — Phase-2 health_check."""
|
|
|
|
from __future__ import annotations
|
|
|
|
import os
|
|
import sys
|
|
|
|
sys.path.insert(0, os.path.join(os.path.dirname(__file__), "..", "..", "..", "runner"))
|
|
from harness import http as harness_http # noqa: E402
|
|
|
|
|
|
def test_plausible_root_serves(live_app):
|
|
"""GET /api/health → 200 (clickhouse+postgres ready).
|
|
|
|
`/` is NOT a reliable health probe (500s during datastore init; 302s to
|
|
/register once ready — and 500'd permanently under the pre-2026-06-11
|
|
62-char SECRET_KEY_BASE, see recipe_meta.EXTRA_ENV); the dedicated
|
|
/api/health endpoint is.
|
|
"""
|
|
# The custom tier runs AFTER the backup/restore tier, which disrupts postgres under the app and
|
|
# restarts it. v3 (community-edition) then boots through `sleep 10` + `db createdb` + `db migrate`
|
|
# + cache warmers before /api/health flips to 200, which does not fit in 60s — that is what put
|
|
# this recipe RED on build 1224 while install/upgrade/backup/restore all passed. The assertion is
|
|
# unchanged (still a hard 200 from the real readiness endpoint); only the wait matches the boot
|
|
# profile the recipe already declares via recipe_meta.HTTP_TIMEOUT (1200).
|
|
url = f"https://{live_app}/api/health"
|
|
status, _ = harness_http.retry_http_get(url, expect_status=(200,), max_wait=300, interval=5)
|
|
assert status == 200, f"GET {url} HTTP {status}"
|