Summary
On a fresh v4 Docker self-host (hosting/docker, combined webapp+worker stack, TRIGGER_IMAGE_TAG=latest → v4.5.5), tasks execute and complete fine, but no runs ever appear in the dashboard run list (and GET /api/v1/runs returns {"data":[]}). Runs exist in Postgres (TaskRun table) — every insert into ClickHouse fails, so the run explorer's backing store stays empty.
Root cause
The compose file defaults to bitnamilegacy/clickhouse:latest. That catalog is frozen — its latest is ClickHouse 25.5.2. The webapp's @clickhouse/client (1.12.1) sends a settings key introduced in newer ClickHouse, and 25.5 rejects the whole insert:
ClickHouseError: Setting input_format_json_infer_array_of_dynamic_from_array_of_different_types
is neither a builtin setting nor started with the prefix 'SQL_' registered for user-defined settings.
{"table":"trigger_dev.metrics_v1", "message":"Error inserting into clickhouse","level":"error"}
Same failure for the runs replication inserts, hence the empty dashboard. Because bitnamilegacy never advances, every new self-hoster on the default compose gets a silently broken run explorer as soon as the webapp image expects newer ClickHouse (the helm values already reference 25.7.5, but the compose default can't even reach that).
Repro
hosting/docker compose stack, defaults, TRIGGER_IMAGE_TAG=latest
- Deploy any project, trigger any task → run completes (visible in
TaskRun in Postgres)
- Dashboard runs list is empty; webapp logs show the insert errors above
Workaround that fixed it for me
Swap the service to the official image (config override.xml and default:password credentials work as-is):
clickhouse:
image: clickhouse/clickhouse-server:25.10
environment:
CLICKHOUSE_USER: ${CLICKHOUSE_USER:-default}
CLICKHOUSE_PASSWORD: ${CLICKHOUSE_PASSWORD:-password}
volumes:
- clickhouse-data:/var/lib/clickhouse
- ../clickhouse/override.xml:/etc/clickhouse-server/config.d/override.xml:ro
After restarting the webapp (schema recreated, replication restarted), new runs show up in the dashboard immediately.
Suggested fix
Move hosting/docker off bitnamilegacy/clickhouse:latest to a pinned official clickhouse/clickhouse-server tag that's tested against the webapp's client — or at minimum pin a compatible tag instead of latest, and surface ClickHouse insert failures more loudly (they're easy to miss while everything else works).
Environment: webapp/supervisor v4.5.5 (latest on 2026-07-21), Docker 29.1.3, Linux amd64.
Summary
On a fresh v4 Docker self-host (
hosting/docker, combined webapp+worker stack,TRIGGER_IMAGE_TAG=latest→ v4.5.5), tasks execute and complete fine, but no runs ever appear in the dashboard run list (andGET /api/v1/runsreturns{"data":[]}). Runs exist in Postgres (TaskRuntable) — every insert into ClickHouse fails, so the run explorer's backing store stays empty.Root cause
The compose file defaults to
bitnamilegacy/clickhouse:latest. That catalog is frozen — itslatestis ClickHouse 25.5.2. The webapp's@clickhouse/client(1.12.1) sends a settings key introduced in newer ClickHouse, and 25.5 rejects the whole insert:Same failure for the runs replication inserts, hence the empty dashboard. Because
bitnamilegacynever advances, every new self-hoster on the default compose gets a silently broken run explorer as soon as the webapp image expects newer ClickHouse (the helm values already reference 25.7.5, but the compose default can't even reach that).Repro
hosting/dockercompose stack, defaults,TRIGGER_IMAGE_TAG=latestTaskRunin Postgres)Workaround that fixed it for me
Swap the service to the official image (config override.xml and
default:passwordcredentials work as-is):After restarting the webapp (schema recreated, replication restarted), new runs show up in the dashboard immediately.
Suggested fix
Move
hosting/dockeroffbitnamilegacy/clickhouse:latestto a pinned officialclickhouse/clickhouse-servertag that's tested against the webapp's client — or at minimum pin a compatible tag instead oflatest, and surface ClickHouse insert failures more loudly (they're easy to miss while everything else works).Environment: webapp/supervisor
v4.5.5(lateston 2026-07-21), Docker 29.1.3, Linux amd64.