Skip to content

Handle concurrent default-group creation during startup #6359

Description

@jhrozek

Summary

thv startup can fail when multiple CLI processes initialize the default group concurrently. This is reproducible in the core E2E shard, which runs Ginkgo with PROCS=4.

Reproduction

Start four processes concurrently against the same fresh state directory:

for i in 1 2 3 4; do
  ./bin/thv --help &
done
wait

With a fresh shared XDG state directory, one process creates the default group and another process exits with:

failed to ensure default group exists
group already exists: default

Root cause

cmd/thv/main.go runs migration.EnsureDefaultGroupExists() for --help because --help is not classified as informational. pkg/migration/migration.go performs an Exists check followed by Create. Concurrent processes can all observe that the group is absent; one wins creation and the others receive groups.ErrGroupAlreadyExists. That expected race is returned as a fatal startup error.

The E2E helper then reports this misleadingly as thv binary not available because it only preserves the command error and discards stderr (test/e2e/helpers.go:367-372).

Expected behavior

If another process creates the default group first, startup should treat groups.ErrGroupAlreadyExists as success and continue.

Suggested validation

Add a regression test that invokes concurrent default-group initialization against a shared local store and verifies all callers succeed. Also preserve stderr in CheckTHVBinaryAvailable so startup failures are diagnosable.

Related PR: #6350

Metadata

Metadata

Assignees

No one assigned

    Labels

    needs-triageIssue needs initial triage by a maintainer

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions