[namastex888]

Summary

After migration 061 (agents_id_invariant_and_fk_lockdown) shipped in v4.260503.7/.8, every new spawn (both genie work and genie spawn) hits:

PostgresError: new row for relation "agents" violates check constraint "agents_id_shape_check"

Constraint requires agents.id to be a UUID (8-4-4-4-12 hex) or dir:% prefix. But generateWorkerId still produces the legacy team-role[-8hex] shape — neither matches.

Root cause

src/term-commands/agents.ts:446:

const base = role ? `${team}-${role}` : team;
if (!existing.some((w) => w.id === base)) return base;
const suffix = crypto.randomUUID().slice(0, 8);
return `${base}-${suffix}`;

Both return paths produce non-UUID strings. Constraint rejects every new INSERT.

Fix (1-line semantic change)

async function generateWorkerId(_team: string, _role?: string): Promise<string> {
  return crypto.randomUUID();
}

agents.id becomes a pure UUID surrogate key. agents.role and agents.customName still carry human-readable identity for display/listing.

Companion to PR #1626

#1626 fixed dispatch role-collision (engineer-3 colliding across wishes). This PR fixes the deeper INSERT-time constraint violation that surfaces after #1626 unblocks the role check. Both are needed.

Validation

• bun run typecheck clean
• After merge: genie work <wish> and genie spawn <role> produce agents with UUID id that pass agents_id_shape_check

Test plan

• genie work autopg-distribution-cutover from a fresh shell dispatches G3 without agents_id_shape_check error
• genie spawn engineer --team genie produces agent row with UUID id
• Existing agents with legacy ids continue working (NOT VALID grandfather clause from migration 061)
• No regression in genie ls, genie agent show <name> — name resolution still works

Out of scope (followups)

• Wider unification of the 3 worker-id paths (TUI nextRoleSuffix, dispatch effectiveRole, this generateWorkerId) — wish-territory
• Migration to backfill legacy non-UUID ids — separate effort

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: ddfd9792-cd31-4805-bc91-f63b8c21ced4

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch wish/worker-id-uuid

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[gemini-code-assist]

Code Review

This pull request updates the generateWorkerId function to always return a random UUID, ensuring compliance with database constraints introduced in a recent migration. However, the reviewer pointed out that this change introduces a regression in idempotency and will likely cause unique constraint violations during agent registration. The feedback suggests retrieving the existing agent's UUID from the registry to maintain stability and avoid database errors.

[gemini-code-assist]

Returning a fresh crypto.randomUUID() here introduces a regression in idempotency and a high risk of database errors due to unique constraint violations.

1. Unique Constraint Violation: In handleWorkerSpawn, registry.findOrCreateAgent is called at line 2621. This function ensures an agent identity exists for the given (custom_name, team) and returns its UUID id. If generateWorkerId then returns a different random UUID, the subsequent registry.register call (line 665, via ctx.workerId) will attempt to insert a new row with the same custom_name and team but a different primary key id. This will trigger a unique constraint violation on the (custom_name, team) composite key.
2. Loss of Stability: The previous implementation produced a stable ID based on team and role. Using a random UUID means every spawn attempt for the same role will try to create a new agent record instead of updating the existing one.
3. Incomplete Fix: This change only addresses the legacy path. The identity.workerId path in handleWorkerSpawn (line 2641) still uses resolveSpawnIdentity, which returns non-UUID strings (e.g., engineer or engineer-abcd). Standard spawns will likely still fail the agents_id_shape_check constraint.

To fix this properly while staying within the current architecture, this function should look up the existing agent's UUID from the registry.

async function generateWorkerId(team: string, role?: string): Promise<string> {
  // Always return a UUID. agents.id constraint (migration 061) requires
  // UUID shape or 'dir:%' prefix. We look up the existing agent identity
  // to ensure we use its canonical UUID and avoid unique constraint violations
  // on (custom_name, team) during registration.
  const name = role || team;
  const existing = await registry.getAgentByName(name, team);
  if (existing) return existing.id;

  return crypto.randomUUID();
}