From 9501da81a075a69d864a6cdf01485e51d4bb5f9e Mon Sep 17 00:00:00 2001 From: Viktor Barzin Date: Sat, 13 Jun 2026 14:22:24 +0000 Subject: [PATCH] dbaas: document postgresql-backup startingDeadlineSeconds rationale Inline note on why the four backup CronJobs moved 10s->600s (bda1bdcb): a 10s deadline silently dropped the 2026-06-13 midnight full-backup run, firing PostgreSQLBackupStale. bda1bdcb rode in the same push as a forgejo change that failed CI on a namespace-quota error, so that pipeline failed before the dbaas apply took effect (live deadline was still 10s). This dbaas-only commit re-triggers the dbaas apply at a clean master so the 600s deadline actually goes live. Co-Authored-By: Claude Opus 4.8 --- stacks/dbaas/modules/dbaas/main.tf | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/stacks/dbaas/modules/dbaas/main.tf b/stacks/dbaas/modules/dbaas/main.tf index 9d450689..479263ed 100644 --- a/stacks/dbaas/modules/dbaas/main.tf +++ b/stacks/dbaas/modules/dbaas/main.tf @@ -1607,6 +1607,11 @@ resource "kubernetes_cron_job_v1" "postgresql-backup" { failed_jobs_history_limit = 5 schedule = "0 0 * * *" # schedule = "* * * * *" + # 600s (was 10s): a 10s deadline silently DROPPED the 2026-06-13 00:00 run + # when the CronJob controller was late at the midnight backup/IO-storm tick, + # leaving the last full dump 37h old (fired PostgreSQLBackupStale). 600s lets + # a brief controller lag still launch the job. Same fix on the other three + # dbaas backup crons (they share the midnight window). starting_deadline_seconds = 600 successful_jobs_history_limit = 10 job_template {