GeezerVison

TODO: Create a proper dbauthz boundary for this

We need to clean this up before merging. History tells me that if we don't get this right before main we won't come back around.

Yup, I'll pause before merging.

Done in ae5b7ea69b. Dropped AsProvisionerd/ResourceSystem entirely. The handler relies on the agent token subject already in the RPC context, and each query authorizes against the workspace that owns the agent in dbauthz (fast path via the cached workspace RBAC object, slow path via GetWorkspaceByAgentID), same as UpdateWorkspaceAgentMetadata. Added TestWorkspaceAgentPushContextState, which pushes through the real agent RPC path (agent token middleware, DRPC v2.10, dbauthz, Postgres) to pin the boundary.

Posted by Coder Agents on Kyle's behalf.

TODO: Proper resource tags for this, not ResourceSystem

Resolved in ae5b7ea69b alongside the boundary change: these wrappers no longer use ResourceSystem. They now fetch the workspace by agent ID and authorize the action against that workspace object (with a fast path through the cached workspace RBAC object from the agent connection).

Posted by Coder Agents on Kyle's behalf.

For most other enumerated types in the database we use a SQL type, which then generates a Go type via sqlc --- why aren't we doing that here?

No good reason; fixed in ae5b7ea69b. body_kind and status are now proper SQL enum types (workspace_agent_context_body_kind, workspace_agent_context_resource_status) and the handler uses the sqlc-generated constants. The reserved plugin RFC kinds are pre-seeded in the enum, so future variants are still just an ALTER TYPE ... ADD VALUE plus a Go switch case.

Posted by Coder Agents on Kyle's behalf.

We only soft-delete agents, so these will accumulate in the database forever. I think we should at least update SoftDeletePriorWorkspaceAgents and SoftDeleteWorkspaceAgentsByWorkspaceID to clean this up, or define a dbpurge job to do so.

Done in ae5b7ea69b. Updated both SoftDeletePriorWorkspaceAgents and SoftDeleteWorkspaceAgentsByWorkspaceID to hard-delete the context rows for the agents being soft-deleted (CTE in the same statement), with a querier test (TestSoftDeleteWorkspaceAgentsPurgesContext). Went with this over a dbpurge job since the rows only describe live agents and agents are never un-deleted.

Posted by Coder Agents on Kyle's behalf.

Following the spirit of this, I found a third soft-delete path that would have leaked: DeleteWorkspaceSubAgentByID (the DeleteSubAgent RPC), which removes a devcontainer sub-agent mid-build without a full workspace rebuild. Because the rebuild-time queries both filter deleted = FALSE (so they skip an already-deleted sub-agent), the FK ON DELETE CASCADE only fires on hard delete, and we never hard-delete agents, that sub-agent's context rows would have orphaned forever.

Fixed in de2c1be by applying the same purge CTE to DeleteWorkspaceSubAgentByID, and extended TestSoftDeleteWorkspaceAgentsPurgesContext to cover the sub-agent case.

Posted by Coder Agents on Kyle's behalf.

I think we need repeatable read isolation here to avoid situations where two different updates are sent simultaneously and klobber each other.

Done in ae5b7ea69b. Switched to database.ReadModifyUpdate, which runs the transaction at repeatable read and retries serialization failures (40001). The loser of a conflict re-runs the version gate against the winner's committed state, so stale pushes get dropped rather than clobbering. Added a unit test (SerializationConflictRetries) covering the retry path.

Posted by Coder Agents on Kyle's behalf.

why not reuse database.UpsertWorkspaceAgentContextResourceParams here instead of defining a new type?

No reason, fixed in ae5b7ea69b. resourceRow is gone; validation now produces database.UpsertWorkspaceAgentContextResourceParams directly and the handler fills WorkspaceAgentID/Now at upsert time.

Posted by Coder Agents on Kyle's behalf.

We need to validate the resource sizes and numbers server-side, otherwise a compromised Workspace can DoS Coderd.

Done in ae5b7ea69b. Added server-side caps, validated before the transaction starts: at most 1000 resources per push, 256KiB per marshaled body, 4MiB aggregate body size (aligned with the DRPC message cap), 1KiB source/source_path (source is a btree PK column, which Postgres limits to ~2704 bytes per index entry), 4KiB error strings, 64B hashes, and explicit uint64 to int64 overflow checks on version/size_bytes. Each cap has a unit test.

Posted by Coder Agents on Kyle's behalf.