Found while reviewing the beta.64 topology branch (#22, #27, #28). Pre-existing on master; the branch only documents it.
Problem
With useHelmHooks=false (the ArgoCD path) the migration Job in templates/server/migration-job.yaml is a PreSync hook on every sync, including the first. The built-in PostgreSQL/MySQL StatefulSet and Service are ordinary Sync-phase resources, so on the first sync the Job starts before the database exists:
DB_HOST points at a Service that is not created yet, the Job exhausts backoffLimit (3) and the PreSync phase fails.- ArgoCD never enters the Sync phase, so the database is never created and the app stays stuck.
- Since the branch, the server also carries
MIGRATION_ENABLED=false in this mode (correct once the Job runs), so nothing else would migrate even if the Sync phase ran.
Plain Helm does not hit this because the Job is pre-upgrade only and fresh installs migrate at boot. External databases are unaffected.
Current mitigation
values.yaml on server.migration.enabled now says: under useHelmHooks=false enable the Job only after the first sync when a built-in database is used. That is a documentation workaround, not a fix.
Suggested fix
Options, roughly in order of effort:
- Make the ArgoCD Job a
Sync-phase hook with a negative sync-wave and put the built-in database StatefulSet/Service at an even lower wave. ArgoCD waits for a wave to be healthy before starting the next one, so the Job would run against a ready database on the first sync and still precede the server Deployment (wave 0). The hook-scoped ConfigMap and migration NetworkPolicy must move to the same phase and an earlier wave. - Skip the Job in that mode when a built-in database is enabled and render a NOTES.txt warning. Loses DDL serialization for built-in stores, which are dev-only anyway.
- Keep documentation only (status quo).
Test for it
helm template t charts/authup -f charts/authup/ci/default-values.yaml \
--set useHelmHooks=false --set server.migration.enabled=true \
--set postgresql.persistence.enabled=true
The Job renders with argocd.argoproj.io/hook: PreSync and DB_HOST=t-authup-postgresql, while the PostgreSQL Service and StatefulSet carry no hook or wave annotations. Whatever the fix, scripts/check-beta64-contract.py should assert the ordering between the database, the Job and the server Deployment on the useHelmHooks=false path.
Found while reviewing the beta.64 topology branch (#22, #27, #28). Pre-existing on master; the branch only documents it.
Problem
With
useHelmHooks=false(the ArgoCD path) the migration Job intemplates/server/migration-job.yamlis aPreSynchook on every sync, including the first. The built-in PostgreSQL/MySQL StatefulSet and Service are ordinary Sync-phase resources, so on the first sync the Job starts before the database exists:DB_HOSTpoints at a Service that is not created yet, the Job exhaustsbackoffLimit(3) and the PreSync phase fails.MIGRATION_ENABLED=falsein this mode (correct once the Job runs), so nothing else would migrate even if the Sync phase ran.Plain Helm does not hit this because the Job is
pre-upgradeonly and fresh installs migrate at boot. External databases are unaffected.Current mitigation
values.yamlonserver.migration.enablednow says: underuseHelmHooks=falseenable the Job only after the first sync when a built-in database is used. That is a documentation workaround, not a fix.Suggested fix
Options, roughly in order of effort:
Sync-phase hook with a negativesync-waveand put the built-in database StatefulSet/Service at an even lower wave. ArgoCD waits for a wave to be healthy before starting the next one, so the Job would run against a ready database on the first sync and still precede the server Deployment (wave 0). The hook-scoped ConfigMap and migration NetworkPolicy must move to the same phase and an earlier wave.Test for it
The Job renders with
argocd.argoproj.io/hook: PreSyncandDB_HOST=t-authup-postgresql, while the PostgreSQL Service and StatefulSet carry no hook or wave annotations. Whatever the fix,scripts/check-beta64-contract.pyshould assert the ordering between the database, the Job and the server Deployment on theuseHelmHooks=falsepath.