timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484) by jacobecox · Pull Request #664 · controlplane-com/templates

jacobecox · 2026-10-26T16:18:02Z

timescaledb-highly-available 1.2.1 moves to timescale/timescaledb-ha:pg18.6-ts2.31.0, whose pgvector is 0.8.7 (the old pg18.4-ts2.28.3 has 0.8.5), fixing CVE-2026-103484: a database user who can build an IVFFlat index can run code as the server (pgvector#1036). Work item 5376. The new tag is also PostgreSQL 18.4 → 18.6 (no dump/restore) and TimescaleDB 2.28.3 → 2.31.0.

Review diff: git diff 321a547e..HEAD -- timescaledb-highly-available/versions/1.2.1/. Commit 321a547 is the verbatim copy of 1.2.0 taken from #628's head (1644e41), so 1.2.1 carries that PR's reviewed wizard and README fix; if #628 changes before merge, 1.2.1 needs the same change.

What changed

Image and appVersion pg18.6-ts2.31.0, lastModified.
tsdb-ha.validateImage (new fail, included from templates/identity.yaml with the other validations) refuses timescale/timescaledb-ha pg18 tags shown (measured) or dated (pushed before pgvector 0.8.7's 2026-10-01 release) to carry pgvector < 0.8.7 — including every default this template has shipped. A blanket "ts < 2.31" rule would be wrong: pg18.6-ts2.30.2 was rebuilt 10-20 and has 0.8.7. Other registries, digests and unrelated tags pass. Mirrored by a wizard rule on the image field. Known limit: if Timescale rebuilds an old pg18 tag with the fix, the guard would still refuse it (noted in the briefing).
README "Upgrading from a version before 1.2.1": the image keeps every TimescaleDB library back to 2.23.0, so an existing database keeps running 2.28.3 after the restart until ALTER EXTENSION timescaledb UPDATE; is run on the leader in a fresh psql -X session (exact commands given); \dx shows the old vector version until ALTER EXTENSION vector UPDATE;; PostgreSQL 18.6 allows only pgoutput/test_decoding logical decoding plugins by default.
wizard: the mirrored rule, an upgrade note, the pg18 example tag. Briefing: defaults and 1.2.1 history.

Default render vs 1.2.0: only the image and version labels differ (also on an all-features render).

Tests (live, test-gvc-2 aws-us-east-1) — 8/8 PASS

Row	Result
Upgrade 1.2.0 → 1.2.1 (values from `tw carry`)	leader re-elected, both members streaming (lag 0), all on PG 18.6 / Patroni 4.1.5. Before the ALTER: timescaledb 2.28.3 still loaded and hypertable (14401 rows), 7 compressed chunks and the continuous aggregate read back unchanged. README commands run verbatim → timescaledb 2.31.0 and vector 0.8.7 on leader and replicas; new ivfflat index builds; compression and aggregate refresh work; all 959 acknowledged probe writes present
Guard live	upgrade with `pg18.4-ts2.28.3` refused; history and workloads unchanged
Fresh install	ready ~5 min, leader + 2 streaming; PG 18.6, timescaledb 2.31.0, vector 0.8.7
Drift	6 probe fields, identical to 1.2.0 (deferred to the drift audit); second no-op upgrade all `Unchanged`
Teardown	janitor `== test-gvc-2 is clean ✓`

Also fixed in 1.2.1 (maintainer rulings 2026-10-26)

Chart upgrades no longer refuse writes for ~74 s (HAProxy startup). Through 1.2.0 the proxy's start script waited for all Patroni members to answer :8008, and the proxy had no readiness probe. The proxy is redeployed in the same apply, so the old proxies were retired while the new ones sat in the gate (73.7 s measured with the leader untouched). Now, as in pgedge 3.0.0:

the start script waits at most 60 s for any member;
HAProxy re-resolves server names at runtime (resolvers mesh);
readinessProbe on /stats :8405, true once HAProxy is listening.

The first probe tried was /healthz :8404, which is true only while a leader is routable. In a hang failover the platform then stopped both proxies, giving a 155 s outage instead of 70 s, so /stats it is.

PgBouncer installs again. ADMIN_USERS read postgres.username, which 1.2.0 removed, so it rendered null and the API rejected the PgBouncer workload; pgbouncer.enabled: true had no workaround. It now reads cpln://secret/<credentialsSecretName>.username, like DB_USER beside it. README upgrade note added.

Proxy/PgBouncer re-test (test-gvc-2), continuous write probe, 0 acknowledged writes lost in every row:

Row	Result
Upgrade 1.2.0 → 1.2.1	one 5.4 s gap (planned handover). The old proxy stayed until a new one was ready, and the leader was routable from the new proxy's first instant
Proxy redeploy while a member is hung (the old gate's worst case)	no gap
3 failovers by hanging the leader	74.7 / 76.4 / 76.4 s, each Patroni's leaderless window plus 1–2 s. 0 proxy restarts
Fresh install	proxy ready 7–8 s after HAProxy started. Writes work once a leader exists. 0 restarts
Runtime DNS	healed a placeholder address to the real mesh address in 32 s, with no restart
PgBouncer install	`deployed`; writes and reads reach the leader; `SHOW POOLS` works as the superuser; wrong credentials refused
Drift	proxy clean. The 6 Patroni probe fields are unchanged from 1.2.0 (deferred)
Teardown	janitor `clean ✓`

Wizard gates

tw lint: ok timescaledb-highly-available 1.2.1 (previous 1.2.0): 0 errors, 0 warnings, 59/59 leaves covered
tw carry from 1.2.0 defaults and from values pinning pg18.4-ts2.28.3 → pg18.6-ts2.31.0, renders
tw check-docs: 1 forward anchor #upgrading-from-a-version-before-1-2-1 (the docs page needs that heading; re-run after the docs PR)

Next: the wizard-verifier round in the test console. Hold for the joint review with the maintainer before merge.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WZ5WWhTn9mEkPY7cLt1cr4

Seeded from 1644e41 (head of unmerged PR #628: 1.2.0's reviewed wizard.yaml + in-place README fix). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WZ5WWhTn9mEkPY7cLt1cr4

…gvector 0.8.7, CVE-2026-103484) - image default pg18.4-ts2.28.3 -> pg18.6-ts2.31.0: pgvector 0.8.5 -> 0.8.7, PostgreSQL 18.4 -> 18.6, TimescaleDB 2.28.3 -> 2.31.0. The image keeps the 2.28.3 library, so existing databases run unchanged until ALTER EXTENSION timescaledb UPDATE. - tsdb-ha.validateImage refuses the pg18 timescale/timescaledb-ha tags built before pgvector 0.8.7 (pinned <= ts2.30.1, frozen pg18-ts2.0..2.29); mirrored wizard rule. - README "Upgrading from a version before 1.2.1"; wizard upgrade note; example tag in the pg18 rule. - Briefing: default image, pg17 fallback caveat, 1.2.1 history. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WZ5WWhTn9mEkPY7cLt1cr4

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

…on every Patroni member The startup gate waited for every member to answer :8008 before starting HAProxy, and the proxy workload had no readiness probe. A chart upgrade redeploys the proxy while Patroni is rolling, so the new proxies were counted ready and the old ones retired while the new ones sat in the gate: writes were refused for ~75-130 s although the leader never moved (measured on all three Patroni charts in 5376 testing). - HAProxy re-resolves server names at runtime (resolvers mesh, copied from pgedge 3.0.0), so a placeholder address from the mesh DNS heals itself; that was the gate's only reason to exist. - The start script waits at most 60s for ANY member's Patroni API, then starts regardless. - readinessProbe on /healthz :8404 (a leader is routable), so an upgrade keeps the old proxy replicas serving until a new one can reach the primary. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WZ5WWhTn9mEkPY7cLt1cr4

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

…ealthz /healthz fails whenever no leader is routable. In a failover by a hung leader (test 2026-10-26, timescaledb-highly-available) readiness stayed false for ~60 s and the platform then stopped both proxy replicas, ~9 s after the new leader was already UP, doubling the outage (155 s vs 70 s). The upgrade overlap only needs HAProxy listening, which /stats :8405 shows (as pgedge). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WZ5WWhTn9mEkPY7cLt1cr4 Also: start-script comments corrected to what testing measured (as on pgha/pgml).

…SERS from the credentials secret) workload-pgbouncer.yaml read .Values.postgres.username, removed in 1.2.0 when credentials moved to a prerequisite secret. It rendered null and the API rejected the PgBouncer workload ("spec.containers[0].env[0].value" must be a string), leaving a failed release; the removed-key guard refuses the old key, so pgbouncer.enabled had no workaround. Read it from the credentials secret, like DB_USER beside it (the policy already grants reveal on that secret). Maintainer ruling 2026-10-26: fix in 1.2.1. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WZ5WWhTn9mEkPY7cLt1cr4

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

… readiness probe Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WZ5WWhTn9mEkPY7cLt1cr4

…uncer fixes, measured Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WZ5WWhTn9mEkPY7cLt1cr4

…orks again Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WZ5WWhTn9mEkPY7cLt1cr4

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

….2.1 hazard; maxDbConnections comment is per pod From the console wizard round (2026-10-27): the 1.2.1 note now also covers the renamed TimescaleDB settings and PostgreSQL 18.6's logical-decoding plugin allowlist (both were README-only) and is a warning, since it asks the user to act. The values comment called maxDbConnections a total across pods; it is per pod, as the README and wizard say. Neither changes the render. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WZ5WWhTn9mEkPY7cLt1cr4

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

github-actions · 2026-10-27T00:55:53Z

Template e2e tests

⚠️ mariadb/1.4.1 — 28/32 passed, 4 warnings (9.8 min, aws-us-east-1)

Scenario	Check	Result
install 1.4.1	install + every workload ready	pass
install 1.4.1	rendered == stored (Console Drift tab)	warn — workload/e2eikkfvez10-maria spec.defaultOptions.autoscaling.maxConcurrency: stored 0, chart omits it; workload/e2eikkfvez10-maria spec.defaultOptions.autoscaling.scaleToZeroDelay: stored 300, chart omits it; workload/e2eikkfvez10-maria spec.defaultOptions.autoscaling.target: stored 95, chart omits it
install 1.4.1	write-read	pass
install 1.4.1	root-login	pass
install 1.4.1	rejects-bad-password	pass
install 1.4.1	data-survives-upgrade	pass
install 1.4.1	no-op upgrade ×2 (no churn)	pass
install 1.4.1	uninstall removes everything	pass
upgrade 1.3.2 → 1.4.1 (new values)	install 1.3.2 (starting point)	pass
upgrade 1.3.2 → 1.4.1 (new values) [before, on 1.3.2]	write-read	pass
upgrade 1.3.2 → 1.4.1 (new values) [before, on 1.3.2]	root-login	pass
upgrade 1.3.2 → 1.4.1 (new values) [before, on 1.3.2]	rejects-bad-password	pass
upgrade 1.3.2 → 1.4.1 (new values) [before, on 1.3.2]	data-survives-upgrade	pass
upgrade 1.3.2 → 1.4.1 (new values)	upgrade to 1.4.1 + every workload ready	pass
upgrade 1.3.2 → 1.4.1 (new values)	rendered == stored (Console Drift tab)	warn — workload/e2eikkfvez10u132-maria spec.defaultOptions.autoscaling.maxConcurrency: stored 0, chart omits it; workload/e2eikkfvez10u132-maria spec.defaultOptions.autoscaling.scaleToZeroDelay: stored 300, chart omits it; workload/e2eikkfvez10u132-maria spec.defaultOptions.autoscaling.target: stored 95, chart omits it
upgrade 1.3.2 → 1.4.1 (new values)	write-read	pass
upgrade 1.3.2 → 1.4.1 (new values)	root-login	pass
upgrade 1.3.2 → 1.4.1 (new values)	rejects-bad-password	pass
upgrade 1.3.2 → 1.4.1 (new values)	data-survives-upgrade	pass
upgrade 1.3.2 → 1.4.1 (new values)	uninstall removes everything	pass
upgrade 1.0.0 → 1.4.1 (new values)	install 1.0.0 (starting point)	pass
upgrade 1.0.0 → 1.4.1 (new values) [before, on 1.0.0]	write-read	pass
upgrade 1.0.0 → 1.4.1 (new values) [before, on 1.0.0]	root-login	pass
upgrade 1.0.0 → 1.4.1 (new values) [before, on 1.0.0]	rejects-bad-password	pass
upgrade 1.0.0 → 1.4.1 (new values) [before, on 1.0.0]	data-survives-upgrade	pass
upgrade 1.0.0 → 1.4.1 (new values)	upgrade to 1.4.1 + every workload ready	pass
upgrade 1.0.0 → 1.4.1 (new values)	rendered == stored (Console Drift tab)	warn — known issue: 1.2.0 renamed the workload and volume set ({release} → {release}-maria-vs), so upgrading from 1.1.x or older starts on a new, empty volume and the data written on 1.0.0 is gone. Left as is by maintainer ruling 2026-10-26; the README says not to upgrade in place. \| workload/e2eikkfvez10u100-maria spec.defaultOptions.autoscaling.maxConcurrency: stored 0, chart omits it; workload/e2e
upgrade 1.0.0 → 1.4.1 (new values)	write-read	pass
upgrade 1.0.0 → 1.4.1 (new values)	root-login	pass
upgrade 1.0.0 → 1.4.1 (new values)	rejects-bad-password	pass
upgrade 1.0.0 → 1.4.1 (new values)	data-survives-upgrade	warn — known issue: 1.2.0 renamed the workload and volume set ({release} → {release}-maria-vs), so upgrading from 1.1.x or older starts on a new, empty volume and the data written on 1.0.0 is gone. Left as is by maintainer ruling 2026-10-26; the README says not to upgrade in place. \| stdout did not match /^PERSISTED$/ (attempt 6/6): MISSING (rows for 1.0.0: 0) WARNING: option --ssl-verify-server-cert
upgrade 1.0.0 → 1.4.1 (new values)	uninstall removes everything	pass

⚠️ mongodb/1.4.1 — 23/27 passed, 4 warnings (7.5 min, aws-us-east-1)

Scenario	Check	Result
install 1.4.1	install + every workload ready	pass
install 1.4.1	rendered == stored (Console Drift tab)	warn — workload/e2eikkfvez11-mongo spec.defaultOptions.autoscaling.maxConcurrency: stored 0, chart omits it; workload/e2eikkfvez11-mongo spec.defaultOptions.autoscaling.scaleToZeroDelay: stored 300, chart omits it; workload/e2eikkfvez11-mongo spec.defaultOptions.autoscaling.target: stored 95, chart omits it; workload/e2eikkfvez11-mongo spec.defaultOptions.timeoutSeconds: stored 5, chart omits it
install 1.4.1	write-read	pass
install 1.4.1	rejects-bad-password	pass
install 1.4.1	data-survives-upgrade	pass
install 1.4.1	no-op upgrade ×2 (no churn)	pass
install 1.4.1	uninstall removes everything	pass
upgrade 1.3.2 → 1.4.1 (new values)	install 1.3.2 (starting point)	pass
upgrade 1.3.2 → 1.4.1 (new values) [before, on 1.3.2]	write-read	pass
upgrade 1.3.2 → 1.4.1 (new values) [before, on 1.3.2]	rejects-bad-password	pass
upgrade 1.3.2 → 1.4.1 (new values) [before, on 1.3.2]	data-survives-upgrade	pass
upgrade 1.3.2 → 1.4.1 (new values)	upgrade to 1.4.1 + every workload ready	pass
upgrade 1.3.2 → 1.4.1 (new values)	rendered == stored (Console Drift tab)	warn — workload/e2eikkfvez11u132-mongo spec.defaultOptions.autoscaling.maxConcurrency: stored 0, chart omits it; workload/e2eikkfvez11u132-mongo spec.defaultOptions.autoscaling.scaleToZeroDelay: stored 300, chart omits it; workload/e2eikkfvez11u132-mongo spec.defaultOptions.autoscaling.target: stored 95, chart omits it; workload/e2eikkfvez11u132-mongo spec.defaultOptions.timeoutSeconds: stored 5, char
upgrade 1.3.2 → 1.4.1 (new values)	write-read	pass
upgrade 1.3.2 → 1.4.1 (new values)	rejects-bad-password	pass
upgrade 1.3.2 → 1.4.1 (new values)	data-survives-upgrade	pass
upgrade 1.3.2 → 1.4.1 (new values)	uninstall removes everything	pass
upgrade 1.0.0 → 1.4.1 (new values)	install 1.0.0 (starting point)	pass
upgrade 1.0.0 → 1.4.1 (new values) [before, on 1.0.0]	write-read	pass
upgrade 1.0.0 → 1.4.1 (new values) [before, on 1.0.0]	rejects-bad-password	pass
upgrade 1.0.0 → 1.4.1 (new values) [before, on 1.0.0]	data-survives-upgrade	pass
upgrade 1.0.0 → 1.4.1 (new values)	upgrade to 1.4.1 + every workload ready	pass
upgrade 1.0.0 → 1.4.1 (new values)	rendered == stored (Console Drift tab)	warn — known issue: 1.2.0 renamed the workload and volume set ({release} → {release}-mongo-vs), so upgrading from 1.1.x or older starts on a new, empty volume and the data written on 1.0.0 is gone. Left as is by maintainer ruling 2026-10-26; the README says not to upgrade in place. \| workload/e2eikkfvez11u100-mongo spec.defaultOptions.autoscaling.maxConcurrency: stored 0, chart omits it; workload/e2e
upgrade 1.0.0 → 1.4.1 (new values)	write-read	pass
upgrade 1.0.0 → 1.4.1 (new values)	rejects-bad-password	pass
upgrade 1.0.0 → 1.4.1 (new values)	data-survives-upgrade	warn — known issue: 1.2.0 renamed the workload and volume set ({release} → {release}-mongo-vs), so upgrading from 1.1.x or older starts on a new, empty volume and the data written on 1.0.0 is gone. Left as is by maintainer ruling 2026-10-26; the README says not to upgrade in place. \| stdout did not match /^PERSISTED$/ (attempt 6/6): MISSING (documents for 1.0.0: 0)
upgrade 1.0.0 → 1.4.1 (new values)	uninstall removes everything	pass

⚠️ mysql/1.5.2 — 31/32 passed, 1 warning (8.3 min, aws-us-east-1)

Scenario	Check	Result
install 1.5.2	install + every workload ready	pass
install 1.5.2	rendered == stored (Console Drift tab)	pass
install 1.5.2	write-read	pass
install 1.5.2	root-login	pass
install 1.5.2	rejects-bad-password	pass
install 1.5.2	data-survives-upgrade	pass
install 1.5.2	no-op upgrade ×2 (no churn)	pass
install 1.5.2	uninstall removes everything	pass
upgrade 1.4.0 → 1.5.2 (new values)	install 1.4.0 (starting point)	pass
upgrade 1.4.0 → 1.5.2 (new values) [before, on 1.4.0]	write-read	pass
upgrade 1.4.0 → 1.5.2 (new values) [before, on 1.4.0]	root-login	pass
upgrade 1.4.0 → 1.5.2 (new values) [before, on 1.4.0]	rejects-bad-password	pass
upgrade 1.4.0 → 1.5.2 (new values) [before, on 1.4.0]	data-survives-upgrade	pass
upgrade 1.4.0 → 1.5.2 (new values)	upgrade to 1.5.2 + every workload ready	pass
upgrade 1.4.0 → 1.5.2 (new values)	rendered == stored (Console Drift tab)	pass
upgrade 1.4.0 → 1.5.2 (new values)	write-read	pass
upgrade 1.4.0 → 1.5.2 (new values)	root-login	pass
upgrade 1.4.0 → 1.5.2 (new values)	rejects-bad-password	pass
upgrade 1.4.0 → 1.5.2 (new values)	data-survives-upgrade	pass
upgrade 1.4.0 → 1.5.2 (new values)	uninstall removes everything	pass
upgrade 1.0.0 → 1.5.2 (new values)	install 1.0.0 (starting point)	pass
upgrade 1.0.0 → 1.5.2 (new values) [before, on 1.0.0]	write-read	pass
upgrade 1.0.0 → 1.5.2 (new values) [before, on 1.0.0]	root-login	pass
upgrade 1.0.0 → 1.5.2 (new values) [before, on 1.0.0]	rejects-bad-password	pass
upgrade 1.0.0 → 1.5.2 (new values) [before, on 1.0.0]	data-survives-upgrade	pass
upgrade 1.0.0 → 1.5.2 (new values)	upgrade to 1.5.2 + every workload ready	pass
upgrade 1.0.0 → 1.5.2 (new values)	rendered == stored (Console Drift tab)	pass
upgrade 1.0.0 → 1.5.2 (new values)	write-read	pass
upgrade 1.0.0 → 1.5.2 (new values)	root-login	pass
upgrade 1.0.0 → 1.5.2 (new values)	rejects-bad-password	pass
upgrade 1.0.0 → 1.5.2 (new values)	data-survives-upgrade	warn — known issue: 1.2.0 renamed the workload and volume set ({release} → {release}-mysql-vs), so upgrading from 1.1.x or older starts on a new, empty volume and the data written on 1.0.0 is gone. Left as is by maintainer ruling 2026-10-26; the README says not to upgrade in place. \| stdout did not match /^PERSISTED$/ (attempt 6/6): MISSING (rows for 1.0.0: 0)
upgrade 1.0.0 → 1.5.2 (new values)	uninstall removes everything	pass

⚠️ pgvector/1.0.0 — 7/8 passed, 1 warning (1.5 min, aws-us-east-1)

Scenario	Check	Result
install 1.0.0	install + every workload ready	pass
install 1.0.0	rendered == stored (Console Drift tab)	warn — workload/e2eikkfvez13-pgvector spec.defaultOptions.autoscaling.maxConcurrency: stored 0, chart omits it; workload/e2eikkfvez13-pgvector spec.defaultOptions.autoscaling.scaleToZeroDelay: stored 300, chart omits it; workload/e2eikkfvez13-pgvector spec.defaultOptions.autoscaling.target: stored 95, chart omits it; workload/e2eikkfvez13-pgvector spec.defaultOptions.timeoutSeconds: stored 5, chart om
install 1.0.0	write-read	pass
install 1.0.0	extension-works	pass
install 1.0.0	rejects-bad-password	pass
install 1.0.0	data-survives-upgrade	pass
install 1.0.0	no-op upgrade ×2 (no churn)	pass
install 1.0.0	uninstall removes everything	pass

⚠️ postgis/1.4.1 — 28/32 passed, 4 warnings (5.4 min, aws-us-east-1)

Scenario	Check	Result
install 1.4.1	install + every workload ready	pass
install 1.4.1	rendered == stored (Console Drift tab)	warn — workload/e2eikkfvez14-postgis spec.defaultOptions.autoscaling.maxConcurrency: stored 0, chart omits it; workload/e2eikkfvez14-postgis spec.defaultOptions.autoscaling.scaleToZeroDelay: stored 300, chart omits it; workload/e2eikkfvez14-postgis spec.defaultOptions.autoscaling.target: stored 95, chart omits it; workload/e2eikkfvez14-postgis spec.defaultOptions.timeoutSeconds: stored 5, chart omits
install 1.4.1	write-read	pass
install 1.4.1	extension-works	pass
install 1.4.1	rejects-bad-password	pass
install 1.4.1	data-survives-upgrade	pass
install 1.4.1	no-op upgrade ×2 (no churn)	pass
install 1.4.1	uninstall removes everything	pass
upgrade 1.3.2 → 1.4.1 (new values)	install 1.3.2 (starting point)	pass
upgrade 1.3.2 → 1.4.1 (new values) [before, on 1.3.2]	write-read	pass
upgrade 1.3.2 → 1.4.1 (new values) [before, on 1.3.2]	extension-works	pass
upgrade 1.3.2 → 1.4.1 (new values) [before, on 1.3.2]	rejects-bad-password	pass
upgrade 1.3.2 → 1.4.1 (new values) [before, on 1.3.2]	data-survives-upgrade	pass
upgrade 1.3.2 → 1.4.1 (new values)	upgrade to 1.4.1 + every workload ready	pass
upgrade 1.3.2 → 1.4.1 (new values)	rendered == stored (Console Drift tab)	warn — workload/e2eikkfvez14u132-postgis spec.defaultOptions.autoscaling.maxConcurrency: stored 0, chart omits it; workload/e2eikkfvez14u132-postgis spec.defaultOptions.autoscaling.scaleToZeroDelay: stored 300, chart omits it; workload/e2eikkfvez14u132-postgis spec.defaultOptions.autoscaling.target: stored 95, chart omits it; workload/e2eikkfvez14u132-postgis spec.defaultOptions.timeoutSeconds: stored
upgrade 1.3.2 → 1.4.1 (new values)	write-read	pass
upgrade 1.3.2 → 1.4.1 (new values)	extension-works	pass
upgrade 1.3.2 → 1.4.1 (new values)	rejects-bad-password	pass
upgrade 1.3.2 → 1.4.1 (new values)	data-survives-upgrade	pass
upgrade 1.3.2 → 1.4.1 (new values)	uninstall removes everything	pass
upgrade 1.0.0 → 1.4.1 (new values)	install 1.0.0 (starting point)	pass
upgrade 1.0.0 → 1.4.1 (new values) [before, on 1.0.0]	write-read	pass
upgrade 1.0.0 → 1.4.1 (new values) [before, on 1.0.0]	extension-works	pass
upgrade 1.0.0 → 1.4.1 (new values) [before, on 1.0.0]	rejects-bad-password	pass
upgrade 1.0.0 → 1.4.1 (new values) [before, on 1.0.0]	data-survives-upgrade	pass
upgrade 1.0.0 → 1.4.1 (new values)	upgrade to 1.4.1 + every workload ready	pass
upgrade 1.0.0 → 1.4.1 (new values)	rendered == stored (Console Drift tab)	warn — known issue: 1.2.0 renamed the workload and volume set ({release} → {release}-postgis-vs), so upgrading from 1.1.x or older starts on a new, empty volume and the data written on 1.0.0 is gone. Left as is by maintainer ruling 2026-10-26; the README says not to upgrade in place. \| workload/e2eikkfvez14u100-postgis spec.defaultOptions.autoscaling.maxConcurrency: stored 0, chart omits it; workload
upgrade 1.0.0 → 1.4.1 (new values)	write-read	pass
upgrade 1.0.0 → 1.4.1 (new values)	extension-works	pass
upgrade 1.0.0 → 1.4.1 (new values)	rejects-bad-password	pass
upgrade 1.0.0 → 1.4.1 (new values)	data-survives-upgrade	warn — known issue: 1.2.0 renamed the workload and volume set ({release} → {release}-postgis-vs), so upgrading from 1.1.x or older starts on a new, empty volume and the data written on 1.0.0 is gone. Left as is by maintainer ruling 2026-10-26; the README says not to upgrade in place. \| stdout did not match /^PERSISTED$/ (attempt 3/3): MISSING (rows for 1.0.0: 0)
upgrade 1.0.0 → 1.4.1 (new values)	uninstall removes everything	pass

⚠️ postgres-highly-available/2.8.0 — 18/20 passed, 2 warnings (14.9 min, aws-us-east-1)

Scenario	Check	Result
install 2.8.0	install + every workload ready	pass
install 2.8.0	rendered == stored (Console Drift tab)	warn — workload/e2eikkfvez15-postgres-ha spec.containers[0].livenessProbe.httpGet.scheme: stored "HTTP", chart omits it; workload/e2eikkfvez15-postgres-ha spec.containers[0].livenessProbe.initialDelaySeconds: stored 60, chart omits it; workload/e2eikkfvez15-postgres-ha spec.containers[0].livenessProbe.successThreshold: stored 1, chart omits it; workload/e2eikkfvez15-postgres-ha spec.containers[0].read
install 2.8.0	cluster-healthy	pass
install 2.8.0	write-read-via-proxy	pass
install 2.8.0	rejects-bad-password	pass
install 2.8.0	data-survives-upgrade	pass
install 2.8.0	no-op upgrade ×2 (no churn)	pass
install 2.8.0	uninstall removes everything	pass
upgrade 2.4.1 → 2.8.0 (new values)	install 2.4.1 (starting point)	pass
upgrade 2.4.1 → 2.8.0 (new values) [before, on 2.4.1]	cluster-healthy	pass
upgrade 2.4.1 → 2.8.0 (new values) [before, on 2.4.1]	write-read-via-proxy	pass
upgrade 2.4.1 → 2.8.0 (new values) [before, on 2.4.1]	rejects-bad-password	pass
upgrade 2.4.1 → 2.8.0 (new values) [before, on 2.4.1]	data-survives-upgrade	pass
upgrade 2.4.1 → 2.8.0 (new values)	upgrade to 2.8.0 + every workload ready	pass
upgrade 2.4.1 → 2.8.0 (new values)	rendered == stored (Console Drift tab)	warn — workload/e2eikkfvez15u241-postgres-ha spec.containers[0].livenessProbe.httpGet.scheme: stored "HTTP", chart omits it; workload/e2eikkfvez15u241-postgres-ha spec.containers[0].livenessProbe.initialDelaySeconds: stored 60, chart omits it; workload/e2eikkfvez15u241-postgres-ha spec.containers[0].livenessProbe.successThreshold: stored 1, chart omits it; workload/e2eikkfvez15u241-postgres-ha spec.co
upgrade 2.4.1 → 2.8.0 (new values)	cluster-healthy	pass
upgrade 2.4.1 → 2.8.0 (new values)	write-read-via-proxy	pass
upgrade 2.4.1 → 2.8.0 (new values)	rejects-bad-password	pass
upgrade 2.4.1 → 2.8.0 (new values)	data-survives-upgrade	pass
upgrade 2.4.1 → 2.8.0 (new values)	uninstall removes everything	pass

❌ redis-cluster/1.7.0 — 15/20 passed, 2 warnings (10.0 min, aws-us-east-1)

Scenario	Check	Result
install 1.7.0	install + every workload ready	pass
install 1.7.0	rendered == stored (Console Drift tab)	warn — workload/e2eikkfvez16-redis-cluster spec.rolloutOptions.maxUnavailableReplicas: chart sends "1", API did not keep it; workload/e2eikkfvez16-redis-cluster spec.rolloutOptions.terminationGracePeriodSeconds: stored 90, chart omits it
install 1.7.0	cluster-healthy	FAIL — stdout did not match /(?s)cluster_state:ok.cluster_slots_assigned:16384.cluster_known_nodes:6$/ (attempt 8/8): cluster_state:fail ⏎ cluster_slots_assigned:0 ⏎ cluster_known_nodes:1
install 1.7.0	write-read	FAIL — stdout did not match /^READ 20/20$/ (attempt 4/4): READ 0/20
install 1.7.0	rejects-bad-password	pass
install 1.7.0	data-survives-upgrade	FAIL — stdout did not match /^PERSISTED$/ (attempt 4/4): MISSING (0/20 keys for 1.7.0)
install 1.7.0	no-op upgrade ×2 (no churn)	pass
install 1.7.0	uninstall removes everything	pass
upgrade 1.4.3 → 1.7.0 (new values)	install 1.4.3 (starting point)	pass
upgrade 1.4.3 → 1.7.0 (new values) [before, on 1.4.3]	cluster-healthy	pass
upgrade 1.4.3 → 1.7.0 (new values) [before, on 1.4.3]	write-read	pass
upgrade 1.4.3 → 1.7.0 (new values) [before, on 1.4.3]	rejects-bad-password	pass
upgrade 1.4.3 → 1.7.0 (new values) [before, on 1.4.3]	data-survives-upgrade	pass
upgrade 1.4.3 → 1.7.0 (new values)	upgrade to 1.7.0 + every workload ready	pass
upgrade 1.4.3 → 1.7.0 (new values)	rendered == stored (Console Drift tab)	warn — workload/e2eikkfvez16u143-redis-cluster spec.rolloutOptions.maxUnavailableReplicas: chart sends "1", API did not keep it; workload/e2eikkfvez16u143-redis-cluster spec.rolloutOptions.terminationGracePeriodSeconds: stored 90, chart omits it
upgrade 1.4.3 → 1.7.0 (new values)	cluster-healthy	pass
upgrade 1.4.3 → 1.7.0 (new values)	write-read	pass
upgrade 1.4.3 → 1.7.0 (new values)	rejects-bad-password	pass
upgrade 1.4.3 → 1.7.0 (new values)	data-survives-upgrade	pass
upgrade 1.4.3 → 1.7.0 (new values)	uninstall removes everything	pass

✅ tidb/2.2.0 — 10/10 passed (6.1 min, aws-us-east-1, aws-us-east-2, aws-us-west-2)

Scenario	Check	Result
install 2.2.0	install + every workload ready	pass
install 2.2.0	rendered == stored (Console Drift tab)	pass
install 2.2.0	stores-up	pass
install 2.2.0	write-read-via-server	pass
install 2.2.0	write-read-via-proxysql	pass
install 2.2.0	root-password-set	pass
install 2.2.0	rejects-bad-password	pass
install 2.2.0	data-survives-upgrade	pass
install 2.2.0	no-op upgrade ×2 (no churn)	pass
install 2.2.0	uninstall removes everything	pass

⚠️ timescaledb/1.2.0 — 18/20 passed, 2 warnings (3.0 min, aws-us-east-1)

Scenario	Check	Result
install 1.2.0	install + every workload ready	pass
install 1.2.0	rendered == stored (Console Drift tab)	warn — workload/e2eikkfvez18-timescaledb spec.defaultOptions.autoscaling.maxConcurrency: stored 0, chart omits it; workload/e2eikkfvez18-timescaledb spec.defaultOptions.autoscaling.scaleToZeroDelay: stored 300, chart omits it; workload/e2eikkfvez18-timescaledb spec.defaultOptions.autoscaling.target: stored 95, chart omits it; workload/e2eikkfvez18-timescaledb spec.defaultOptions.timeoutSeconds: stored
install 1.2.0	write-read	pass
install 1.2.0	extension-works	pass
install 1.2.0	rejects-bad-password	pass
install 1.2.0	data-survives-upgrade	pass
install 1.2.0	no-op upgrade ×2 (no churn)	pass
install 1.2.0	uninstall removes everything	pass
upgrade 1.1.1 → 1.2.0	install 1.1.1 (starting point)	pass
upgrade 1.1.1 → 1.2.0 [before, on 1.1.1]	write-read	pass
upgrade 1.1.1 → 1.2.0 [before, on 1.1.1]	extension-works	pass
upgrade 1.1.1 → 1.2.0 [before, on 1.1.1]	rejects-bad-password	pass
upgrade 1.1.1 → 1.2.0 [before, on 1.1.1]	data-survives-upgrade	pass
upgrade 1.1.1 → 1.2.0	upgrade to 1.2.0 + every workload ready	pass
upgrade 1.1.1 → 1.2.0	rendered == stored (Console Drift tab)	warn — workload/e2eikkfvez18u111-timescaledb spec.defaultOptions.autoscaling.maxConcurrency: stored 0, chart omits it; workload/e2eikkfvez18u111-timescaledb spec.defaultOptions.autoscaling.scaleToZeroDelay: stored 300, chart omits it; workload/e2eikkfvez18u111-timescaledb spec.defaultOptions.autoscaling.target: stored 95, chart omits it; workload/e2eikkfvez18u111-timescaledb spec.defaultOptions.timeou
upgrade 1.1.1 → 1.2.0	write-read	pass
upgrade 1.1.1 → 1.2.0	extension-works	pass
upgrade 1.1.1 → 1.2.0	rejects-bad-password	pass
upgrade 1.1.1 → 1.2.0	data-survives-upgrade	pass
upgrade 1.1.1 → 1.2.0	uninstall removes everything	pass

Run logs

github-actions · 2026-10-27T00:55:54Z

@jacobecox template e2e tests failed, so this PR cannot merge yet. See the report above and the run logs.

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

jacobecox · 2026-10-27T16:34:50Z

Combined into #685 so work item 5376 is one merge (maintainer request). This branch is merged into it unchanged; the write-up and test evidence above stay the reference for this template.

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

- plan and the coverage gate compared a PR against pull_request.base.sha, which is main as of when the PR was opened, so every test merged since counted as the PR's own change: #664 (timescaledb-ha only) ran 12 unrelated templates for 35 min and went red on one of them. The checkout is the PR merged onto today's main, so diff against its first parent. - after helm --wait, poll get-deployments until every location has its desiredScale replicas, all ready, on two polls in a row. On #664 the redis-cluster install was reported ready while node 5 was still starting, and every cluster check timed out (same as elasticsearch #678). Claude-Session: https://claude.ai/code/session_01FZrfgWEQM4Kb8nMRmMPHEC Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

jacobecox and others added 2 commits October 23, 2026 17:48

github-actions Bot added a commit that referenced this pull request Oct 26, 2026

sync-test: merge #664 719acce

07995af

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

github-actions Bot added a commit that referenced this pull request Oct 26, 2026

sync-test: merge #664 719acce

c05a436

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

github-actions Bot added a commit that referenced this pull request Oct 26, 2026

sync-test: merge #664 719acce

a47cfa6

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

github-actions Bot added a commit that referenced this pull request Oct 26, 2026

sync-test: merge #664 719acce

291bdb1

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

github-actions Bot added a commit that referenced this pull request Oct 26, 2026

sync-test: merge #664 719acce

cffbeed

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

github-actions Bot added a commit that referenced this pull request Oct 26, 2026

sync-test: merge #664 719acce

defab53

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

github-actions Bot added a commit that referenced this pull request Oct 26, 2026

sync-test: merge #664 719acce

f907447

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

github-actions Bot added a commit that referenced this pull request Oct 26, 2026

sync-test: merge #664 719acce

459ded3

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

github-actions Bot added a commit that referenced this pull request Oct 26, 2026

sync-test: merge #664 719acce

10fca81

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

github-actions Bot added a commit that referenced this pull request Oct 26, 2026

sync-test: merge #664 719acce

ca03363

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

jacobecox mentioned this pull request Oct 26, 2026

postgres-highly-available 2.8.1: pgvector 0.8.7 (CVE-2026-103484) + no write outage on chart upgrades #674

Closed

github-actions Bot added a commit that referenced this pull request Oct 26, 2026

sync-test: merge #664 719acce

4457dc7

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

github-actions Bot added a commit that referenced this pull request Oct 26, 2026

sync-test: merge #664 719acce

684465b

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

github-actions Bot added a commit that referenced this pull request Oct 26, 2026

sync-test: merge #664 719acce

14dc7dd

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

jacobecox and others added 2 commits October 26, 2026 15:05

github-actions Bot added a commit that referenced this pull request Oct 26, 2026

sync-test: merge #664 719acce

97df3ae

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

github-actions Bot added a commit that referenced this pull request Oct 26, 2026

sync-test: merge #664 719acce

da964b8

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

jacobecox and others added 3 commits October 26, 2026 16:10

timescaledb-highly-available: start-script comment matches the /stats…

128bb00

… readiness probe Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WZ5WWhTn9mEkPY7cLt1cr4

timescaledb-highly-available 1.2.1: briefing — proxy startup and PgBo…

28ba4d7

…uncer fixes, measured Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WZ5WWhTn9mEkPY7cLt1cr4

timescaledb-highly-available 1.2.1: README upgrade note — PgBouncer w…

d7b9b40

…orks again Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WZ5WWhTn9mEkPY7cLt1cr4

github-actions Bot added a commit that referenced this pull request Oct 26, 2026

sync-test: merge #664 d7b9b40

d9d4355

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

github-actions Bot added a commit that referenced this pull request Oct 26, 2026

sync-test: merge #664 d7b9b40

bb718a5

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

github-actions Bot added a commit that referenced this pull request Oct 26, 2026

sync-test: merge #664 d7b9b40

86c777e

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

github-actions Bot added a commit that referenced this pull request Oct 26, 2026

sync-test: merge #664 d7b9b40

b984cee

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

github-actions Bot added a commit that referenced this pull request Oct 26, 2026

sync-test: merge #664 d7b9b40

049f729

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

github-actions Bot added a commit that referenced this pull request Oct 26, 2026

sync-test: merge #664 d7b9b40

f6e99d2

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

github-actions Bot added a commit that referenced this pull request Oct 26, 2026

sync-test: merge #664 d7b9b40

63c108f

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

github-actions Bot added a commit that referenced this pull request Oct 26, 2026

sync-test: merge #664 d7b9b40

766f749

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

jacobecox deployed to e2e-nifah October 27, 2026 00:20 — with GitHub Actions Active

jacobecox had a problem deploying to e2e-nifah October 27, 2026 00:20 — with GitHub Actions Failure

jacobecox deployed to e2e-nifah October 27, 2026 00:20 — with GitHub Actions Active

github-actions Bot added a commit that referenced this pull request Oct 27, 2026

sync-test: merge #664 0e63ef5

15c7b7c

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

github-actions Bot added a commit that referenced this pull request Oct 27, 2026

sync-test: merge #664 0e63ef5

7914a2b

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

github-actions Bot added a commit that referenced this pull request Oct 27, 2026

sync-test: merge #664 0e63ef5

32102a9

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

github-actions Bot added a commit that referenced this pull request Oct 27, 2026

sync-test: merge #664 0e63ef5

a3892ad

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

github-actions Bot added a commit that referenced this pull request Oct 27, 2026

sync-test: merge #664 0e63ef5

69d3be2

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

github-actions Bot added a commit that referenced this pull request Oct 27, 2026

sync-test: merge #664 0e63ef5

69dccc2

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

github-actions Bot added a commit that referenced this pull request Oct 27, 2026

sync-test: merge #664 0e63ef5

0f05e9e

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

github-actions Bot added a commit that referenced this pull request Oct 27, 2026

sync-test: merge #664 0e63ef5

96366d8

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

github-actions Bot added a commit that referenced this pull request Oct 27, 2026

sync-test: merge #664 0e63ef5

2a91562

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

github-actions Bot added a commit that referenced this pull request Oct 27, 2026

sync-test: merge #664 0e63ef5

f39cbe5

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

jacobecox mentioned this pull request Oct 27, 2026

Vulnerability fixes (5376): 13 image bumps + pgvector CVE in 14 bundling templates #685

Merged

jacobecox closed this Oct 27, 2026

github-actions Bot added a commit that referenced this pull request Oct 27, 2026

sync-test: merge #664 0e63ef5

b1324dd

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)

jacobecox mentioned this pull request Oct 27, 2026

e2e: diff PRs against today's main; wait for every replica (5161) #688

Merged

Navigation Menu

Repository navigation

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484) - #664

timescaledb-highly-available 1.2.1: pgvector 0.8.7 (CVE-2026-103484)#664
jacobecox wants to merge 9 commits into
mainfrom
jacob/timescaledb-highly-available-1.2.1

jacobecox commented Oct 26, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Oct 27, 2026

Uh oh!

github-actions Bot commented Oct 27, 2026

Uh oh!

jacobecox commented Oct 27, 2026

Uh oh!

This branch was successfully deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

jacobecox commented Oct 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What changed

Tests (live, test-gvc-2 aws-us-east-1) — 8/8 PASS

Also fixed in 1.2.1 (maintainer rulings 2026-10-26)

Wizard gates

Uh oh!

github-actions Bot commented Oct 27, 2026

Template e2e tests

⚠️ mariadb/1.4.1 — 28/32 passed, 4 warnings (9.8 min, aws-us-east-1)

⚠️ mongodb/1.4.1 — 23/27 passed, 4 warnings (7.5 min, aws-us-east-1)

⚠️ mysql/1.5.2 — 31/32 passed, 1 warning (8.3 min, aws-us-east-1)

⚠️ pgvector/1.0.0 — 7/8 passed, 1 warning (1.5 min, aws-us-east-1)

⚠️ postgis/1.4.1 — 28/32 passed, 4 warnings (5.4 min, aws-us-east-1)

⚠️ postgres-highly-available/2.8.0 — 18/20 passed, 2 warnings (14.9 min, aws-us-east-1)

❌ redis-cluster/1.7.0 — 15/20 passed, 2 warnings (10.0 min, aws-us-east-1)

✅ tidb/2.2.0 — 10/10 passed (6.1 min, aws-us-east-1, aws-us-east-2, aws-us-west-2)

⚠️ timescaledb/1.2.0 — 18/20 passed, 2 warnings (3.0 min, aws-us-east-1)

Uh oh!

github-actions Bot commented Oct 27, 2026

Uh oh!

jacobecox commented Oct 27, 2026

Uh oh!

This branch was successfully deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

jacobecox commented Oct 26, 2026 •

edited

Loading