You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(tables): restore audit provenance and conflict status in orchestration
Moving the audits into the orchestration functions dropped three things the
routes had been carrying, and added one the orchestration now owns twice.
- The v1 and v2 column-update routes passed `request` to `recordAudit`, so
their audit rows recorded the caller's IP and user-agent. The orchestration
function had no way to receive it. Every table orchestration function now
takes an optional `OrchestrationRequestContext` and every HTTP route
forwards it; the copilot and VFS callers, which have no request, omit it.
- `classifyTableMutation` matched `TableConflictError` on "already exists"
appearing in the message and reported it as `validation`, turning the UI
route's 409 on a duplicate table rename into a 400. It now matches the type,
the way `performRestoreTable` already did.
- `captureServerEvent` ran on every delete while the audit was gated on a row
actually being archived, so a repeat delete of an archived table still
reported `table_deleted`. Both now hang off the same evidence.
- The copilot delete path kept its own `captureServerEvent` from when the
service did not emit one, double-counting every copilot table delete.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YGzbVDZpe2dEALbu2BUU8a
0 commit comments