Known issues

Without read committed snapshot isolation, SQL Server takes shared locks for reads, so an ordinary SELECT can be picked as the victim of a deadlock with a concurrent write and the request fails. The same workload never deadlocks on PostgreSQL or MySQL. The engine checks this at boot and logs the exact statements when either database is missing the setting. It does not run them itself: the ALTER waits for exclusive access with no lock timeout, so issuing it against a live database blocks until every other session disconnects, and the ROLLBACK IMMEDIATE form disconnects them instead. Choosing the window is the operator's call.

Presigning and multipart are driver capabilities rather than engine features. The local filesystem driver implements neither, so the five presign and multipart routes answer 501 Not Implemented on an install whose selected provider is local. This is the deliberate answer: the operation is not implemented by this deployment's driver, which is a property of the configuration and not a fault, so it is not reported as a 500.

Running the same erasure twice against SQL Server can report a non-zero affected-row count on the second pass where PostgreSQL and MySQL report zero. The first pass anonymizes the subject's address and leaves the account row, and a row written between the two passes carries the already anonymized address, so the second pass matches it. The end state is correct either way. Only the count is misleading.

A request that omitted the tenant header took a branch that listed every tenant's configured providers instead of none. The list now fails closed: a request with no resolvable tenant is refused rather than answered from an unscoped query.

The endpoint is restricted to platform-level super_admins and identified them by an empty tenant claim. Tenancy resolution stamps a tenant on every authenticated caller, so the platform account carried the default tenant and was refused by the guard meant to protect it. The check now refuses only a caller scoped to a real tenant.

Starting a replay checked for a running one and then created a record, with nothing between the two steps, so two requests arriving together both passed the check and both were accepted. The check and the create are now serialized, and only one of a concurrent pair is accepted.