Skip to content

auth: add high-fanout stress variant of bootstrap-race integration test #64

Description

@cristim

Context

Surfaced during adversarial review of PR LeanerCloud/cloud-commitments-cli#1227 (admin-bootstrap race fix).

PR LeanerCloud/cloud-commitments-cli#1227 added TestIntegration_CreateAdminIfNone_ConcurrentBootstrapOnce in internal/auth/store_postgres_db_test.go, which fires two goroutines × 25 barrier-synced iterations. PR body confirms this reliably fails (2 winners) against the pre-fix code, so it does catch the race.

Gap

Two callers is the production UX (two operators bootstrapping at the same time), but it's the bare minimum for a race that needs serialization. A wider concurrency factor (N=10-100) would:

  1. Harden the regression net against a future "optimization" that subtly weakens the lock (e.g. someone switching from pg_advisory_xact_lock to pg_try_advisory_xact_lock and silently dropping a contender).
  2. Stress the connection pool / pgxpool semaphore behavior under heavy contention on the bootstrap lock.
  3. Catch any code path that accidentally bypasses the tx (e.g. someone refactoring to use s.db.Exec instead of tx.Exec for the INSERT).

Proposal

Add a higher-fanout variant (e.g. TestIntegration_CreateAdminIfNone_ConcurrentBootstrapOnce_Stress) with numGoroutines = 50 and iterations = 10, behind the same integration build tag. Use the same barrier-channel + send outcomes via channel pattern (matches feedback_require_in_goroutines.md and feedback_no_sleep_in_tests.md). Keep the existing 2-goroutine test as the cheap fast-path; the stress variant runs the same assertions (exactly 1 winner, exactly 1 admin row).

Acceptance criteria

  • New test asserts winners == 1 and CountGroupMembers(DefaultAdminGroupID) == 1 with N≥50 concurrent callers across multiple iterations.
  • Test fails reliably against the pre-fix code path (no advisory lock) — verifiable by reverting just the pg_advisory_xact_lock line locally.
  • Worker goroutines only push outcome{} over a channel; all require.* calls stay on the test goroutine.

Priority

Optional — current test catches the race. This would harden against future regressions, not fix a real bug.

No activity

Activity on this issue will appear here.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions