mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-10-27 19:35:13 +01:00
TonioandPaperclip
bec4f4550e
Greptile P1s on the seed receiver: 1. Concurrent application duplicated entities. Cloud's reconcile runs off portfolio fetches that can overlap, so the same company could be pushed twice at once; both passed the revision check before either wrote the seed record, each creating a goal, an agent and an Onboarding project. The issue idempotency key only serialized issue creation. Wrap the whole application in a transaction that first takes a per-company advisory lock (`pg_advisory_xact_lock`), the same idiom `folders` and `decision-queues` use, so the second push observes the first's writes and updates in place. All reads/writes now go through the locked transaction. 2. A revised first task kept stale relationships. When a later revision added an agent or goal for a task that already existed, the update branch set only title/description, leaving the issue's `assigneeAgentId`/`goalId` null or stale while the seed record reported the new relationships. Carry the resolved agent and goal onto the update too (only when present, so an absent value never clears an assignment the tenant made). 3. A failed audit write left the entry permanently absent. The seed and its revision commit before the route logs `company.onboarding_seed_applied`; if that log threw, the request 500'd and the next Cloud retry returned `changed: false` and skipped logging for good — for an application that had in fact succeeded. Make the audit write best-effort: a failure is logged server-side and the request still answers 200, matching the "any 2xx means applied" contract Cloud relies on. Tests: two racing identical pushes yield exactly one goal/agent/project/ task, and a later revision that adds an agent refreshes the existing task's assignee and goal. `vitest run onboarding-seed-route.test.ts` — 13 passing. Co-Authored-By: Paperclip <noreply@paperclip.ing>