Bump production OpenFGA to v1.18.2 - #28
Conversation
Migration-free on Postgres: assets 001-006 are identical at v1.15.1 and v1.18.2, confirmed empirically by running v1.18.2 migrate against a v1.15.1-migrated database (no-op, verified via goose_db_version directly). The v1.18.0 operational warning covers MySQL schema migration 008 only; this deployment is Postgres. Rollback is a pin revert with no schema to undo. Zitadel and zitadel-login pins are untouched.
|
Warning Review limit reached
Next review available in: 5 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughOpenFGA runtime and migration services were upgraded from v1.15.1 to v1.18.2. System administration documentation and the upgrade plan now record the updated versions and verification findings. ChangesOpenFGA upgrade
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/superpowers/plans/2026-08-04-openfga-1182-upgrade.md (1)
95-105: 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick winMake the migration check fail closed.
This Step 5 block only starts Postgres and sleeps before running the migrations, then records Step 5 as complete if later scripts continue. Use a ready probe that targets the
openfgarole/database and add fail-fast behavior so a failedopenfga/openfga:v1.15.1 migrateoropenfga/openfga:v1.18.2 migratecannot be recorded as confirmed.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/superpowers/plans/2026-08-04-openfga-1182-upgrade.md` around lines 95 - 105, Update Step 5 to enable fail-fast shell behavior so either OpenFGA migrate command failure stops the check. Replace the fixed sleep with a readiness probe against the Postgres instance using the openfga role and database, and only run the migrations after readiness succeeds; preserve both version checks and ensure failures cannot leave the step marked complete.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@docs/superpowers/plans/2026-08-04-openfga-1182-upgrade.md`:
- Around line 95-105: Update Step 5 to enable fail-fast shell behavior so either
OpenFGA migrate command failure stops the check. Replace the fixed sleep with a
readiness probe against the Postgres instance using the openfga role and
database, and only run the migrations after readiness succeeds; preserve both
version checks and ensure failures cannot leave the step marked complete.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 17345a71-8f28-4b72-a182-cacebe0a8ad6
📒 Files selected for processing (3)
auth/docker-compose.prod.ymldocs/SYSADMIN.mddocs/superpowers/plans/2026-08-04-openfga-1182-upgrade.md
…ppet CodeRabbit flagged Task 1 Step 5: a fixed sleep instead of a Postgres readiness probe, and no fail-fast between the two migrate runs, meant a failed v1.15.1 migrate could go unnoticed because the v1.18.2 migrate would then "succeed" by migrating the untouched database from scratch, disproving the very claim the step exists to verify. Add set -euo pipefail so any failing command aborts the block, and replace the sleep with a bounded pg_isready poll against the openfga role/database before either migrate runs. Re-ran the snippet end to end: happy path applies goose versions 0-6 via v1.15.1 and nothing via v1.18.2; a forced first-migrate failure (nonexistent database) now aborts before the second migrate runs.
|
Addressed the CodeRabbit finding on Task 1 Step 5 of The reported issue: the block started Postgres, Fix: added Validated by actually running the rewritten snippet in local throwaway containers (network
All test containers and the network were removed afterward; confirmed clean via |
Production OpenFGA has been running v1.18.2 since 2026-08-04 10:53Z. The operator pulled the image in the Plesk Docker interface and recreated the container; Plesk does not write back to git, so auth/docker-compose.prod.yml still said v1.15.1 for a day afterwards. The upgrade plan was written from that stale pin and therefore described an upgrade that had already happened. PR #28 was a correction of the compose file, not a version bump, despite its title. - SYSADMIN 5.4 now records the running version, when it changed, how it was changed, and that it was verified from the container's own startup log (build.version v1.18.2, commit 560d5d3d) rather than from a file. - SYSADMIN 10.3 gains the general lesson: docker-compose.prod.yml is not authoritative for what is running, because the Plesk Docker extension can recreate a container from its UI without touching git. Check .Config.Image and the service's own build.version before trusting a pin. - The plan's Task 5 is marked superseded with the evidence, and kept as the runbook for the next version change — noting that its premise will need re-checking first. Task 1's verification is unaffected and still load-bearing: it proved empirically that 1.15.1 -> 1.18.2 applies no Postgres migration, which is what makes the already-performed upgrade safe rather than lucky. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
1 participant
What this is
Image pin bump only:
openfga/openfga:v1.15.1→v1.18.2inauth/docker-compose.prod.yml(both theopenfgaservice and the one-shotmigrateservice), plus the matching rows in thedocs/SYSADMIN.mdcomponent inventory. Nothing else in the compose file changes —ghcr.io/zitadel/zitadel:v4.15.0andghcr.io/zitadel/zitadel-login:v4.15.0are untouched (verified withgrep -n "zitadel:v\|zitadel-login:v"before and after).Migration-free on Postgres
Task 1 of this upgrade plan verified this empirically against the real v1.18.2 image, not by reading release notes: running v1.18.2's
migrateagainst a v1.15.1-migrated Postgres database is a no-op. This was confirmed by inspectinggoose_db_versiondirectly (unchanged before/after), not by reading migrate's log output. Assets 001-006 are identical between v1.15.1 and v1.18.2. The v1.18.0 operational warning about migration 008 applies only to MySQL; this deployment is Postgres, so it does not apply. Preshared-key auth is unchanged, and/usr/local/bin/grpc_health_probeis still present in the v1.18.2 image, so the existing healthcheck needs no changes.Rollback
If anything looks wrong after restart, rollback is just reverting this pin back to
v1.15.1and restarting. There is no schema migration to undo either direction.What merging does — and does not — do
Merging this PR only lets
sync-to-vps.ymlfast-forward the new compose file onto the VPS at/opt/cdcf-auth. It does not restart anything. The containers keep running on 1.15.1 until an operator deliberately brings the stack down and back up (docker compose -f auth/docker-compose.prod.yml up -d) — that restart, and the checks below, are Task 5 of the plan and are intentionally not part of this PR.Post-restart checks (Task 5, for the record)
Once an operator restarts the stack, Task 5 calls for:
Checkcall against OpenFGA succeeding (not just a health probe) to confirm the API is actually serving authorization decisions correctly post-upgrade.Scope of this PR
auth/docker-compose.prod.yml— twoimage:pins bumped, nothing else.docs/SYSADMIN.md— the two OpenFGA rows in the component inventory table.No SSH, no
.env.productionreads, and no provisioning commands were run as part of this PR — this is a file edit describing production, not a touch of production itself.Summary by CodeRabbit