viktor/infra
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

broker-sync(imap): fix command name + add fsGroup for sync.db writes

Browse source 
Two latent issues found while diagnosing why the May 2026 META vest
didn't land:

1. broker-sync-imap CronJob's command was 'broker-sync imap', but the
   actual CLI subcommand is 'imap-ingest'. Every scheduled run had
   been failing with 'No such command imap' since day-one.

2. Pod runs as uid=10001 gid=999; PVC /data dir is mode 2775
   group=10001. Without fsGroup in the pod's securityContext the
   pod gets only 'other' (r-x) perms on the dir, so sqlite3 can't
   create journal/WAL files next to sync.db -- hits
   'attempt to write a readonly database'. fsGroup=10001 adds the
   matching gid to the pod's supplemental groups so writes work.

Schwab email-sender regex fix is in broker-sync@d860aef.
This commit is contained in:
Viktor Barzin 2026-05-22 14:41:29 +00:00 • committed by Viktor Barzin
parent fa536cc08b
commit 6367b783c7
1 changed files with 11 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

12
stacks/broker-sync/main.tf
View file

@ -271,10 +271,20 @@ resource "kubernetes_cron_job_v1" "imap" {
}
spec {
restart_policy = "OnFailure"
# The broker image's user is uid=10001 gid=999, but the shared
# data PVC's /data root was created with gid=10001 (legacy from
# an earlier image build). Without fsGroup the pod can't write
# to the directory — sqlite3 can't create the journal next to
# sync.db, hits 'attempt to write a readonly database'.
# fsGroup=10001 adds the matching gid to the pod's supplemental
# groups so writes succeed.
security_context {
fs_group = 10001
}
container {
name = "broker-sync"
image = local.broker_sync_image
command = ["broker-sync", "imap"]
command = ["broker-sync", "imap-ingest"]
env {
name = "BROKER_SYNC_DATA_DIR"