[#634] Await agent DB writes and handle cache failures gracefully

[realproject7]

Summary

• AgentRegister.tsx: Awaits DB write after on-chain registration, shows warning if cache fails instead of silent swallowing.
• AgentManage.tsx: Awaits all three DB writes (URI update, wallet bind, wallet unbind) with user-friendly warning on failure.
• agent-register/route.ts: Added 23505 unique violation handling — re-queries and updates the conflicting row instead of throwing.
• agents/page.tsx + AgentDashboard.tsx: cacheAgentById retries once on failure before giving up.

On-chain success is never blocked by DB failure.

Fixes #634
Tracks realproject7/agent-os#314

Test plan

• Agent register awaits DB write and shows warning if it fails
• Agent manage actions (URI update, wallet bind/unbind) await DB writes
• Rapid re-registration doesn't 500 (23505 handled)
• cacheAgentById retries once on failure
• Build passes

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
plotlink	Ignored		Mar 30, 2026 7:22pm

[project7-interns]

Verdict: REQUEST CHANGES

Summary

The UI now waits for the cache-write requests, but the warning path is still incomplete because the API routes can report success even when the DB write fails.

Findings

• [high] agent-update ignores Supabase update errors and still returns { ok: true }, so the new awaited fetch("/api/user/agent-update") calls in AgentManage.tsx will still show success even when the cache write actually failed.
  • File: src/app/api/user/agent-update/route.ts:80
  • Suggestion: Check the returned error from supabase.from("users").update(...) and return a non-2xx response when the DB write fails so the UI can surface the warning state the issue requires.
• [high] agent-register has the same problem on its update paths, so AgentRegister.tsx can still miss cache-write failures after on-chain success.
  • File: src/app/api/user/agent-register/route.ts:64
  • Suggestion: Validate the result of the update(...) calls for both the normal existing-user path and the 23505 retry path, and return a failure status if the DB update did not succeed.

Decision

Requesting changes because the acceptance criteria require cache-write failures to be visible to the user after on-chain success, and the current API routes can still mask those failures behind 200 OK responses.

[project7-interns]

Verdict: REQUEST CHANGES

Summary

The routes now propagate most DB write failures correctly, but the 23505 recovery path in agent-register can still report success without actually updating any row.

Findings

• [high] On the 23505 branch, if the follow-up lookup does not return a row, the handler falls through to { ok: true } even though the insert failed and no update was applied.
  • File: src/app/api/user/agent-register/route.ts:75
  • Suggestion: Treat "conflict but no matching row found" as a failure path and return a non-2xx response. Otherwise the client still shows cache success on an unresolved race, which defeats the new warning behavior.

Decision

Requesting changes because the conflict-recovery path is still not reliable end to end: an unresolved 23505 can be masked as success, so rapid re-registration can still silently skip the cache write.

[project7-interns]

Verdict: APPROVE

Summary

The reliability changes now satisfy the requested scope: the cache-write routes propagate DB failures back to the client, the 23505 recovery path no longer falls through as success, and the client flows await cache writes without blocking on-chain success.

Findings

• None.

Decision

Approving on code review. The earlier error-propagation and conflict-fallthrough issues are addressed; remaining CI checks are still running, but they do not block the review verdict.