perf(syncer): skip no-op commits in group membership/ownership reconcile

[somethingnew2-0]

What & why

Profiling the sync cron showed the group membership/ownership phase dominates the ~26-min run, and — surprisingly — raising --group-fetch-concurrency didn't help: Okta's /api/v1/groups* rate limit sat at ~50% utilization regardless of the setting. That rules out fetch concurrency as the bottleneck; the sync is bound by the serial per-group DB round trips in the reconcile loops.

Each group did a SELECT (current members/owners) and a commit() — two round trips per group. But in authoritative mode the reconciliation writes to Okta, not the DB, so the per-group commit() is a no-op: pure overhead, ~N wasted round trips.

This commits only when a group actually wrote to the DB (non-authoritative drift), plus once every _RECONCILE_COMMIT_EVERY (100) groups to release the read snapshot the SELECTs hold. For a steady-state authoritative run that roughly halves the per-group DB round trips.

What it deliberately does not do

• No bulk-load of all memberships. A start-of-run snapshot would (a) balloon pod memory (relevant given past OOMs) and (b) go stale over the ~26-min run — in authoritative mode a stale view could re-push a membership a concurrent UI change had just removed. The per-group SELECT stays, so each group reads fresh committed state.
• Freshness is safe because Postgres defaults to READ COMMITTED: even with the read transaction held open across several groups, each SELECT sees a fresh snapshot of committed data, including UI changes made mid-run. The periodic commit just bounds how long that read snapshot pins xmin.

Notes

• Non-authoritative drift groups still commit per group, preserving their failure isolation.
• Builds on the merged perf(syncer): stream group prefetch as a bounded sliding window #549 (sliding-window prefetch) and fix(okta): retry transient errors once on the pooled client path #547 (transient retry); this is the piece that actually moves the wall-clock.

🤖 Generated with Claude Code

[somethingnew2-0]

Not sure if I like this solution. It feels like a hack and database commits probably don't outweigh database loads of group memberships being reducing the number of requests to the database being made.

[somethingnew2-0]

Closing for now