Traps to Know About

Five behaviors, all observed on a live installation, that will mislead you if you do not know about them.

1. The two audit tables use different time zones

ArchiveRequests.CreatedAt and ProcessedAt are UTC. ArchiveAudit.ProcessedDate is server local time. On one run: request ProcessedAt 04:19:02, audit ProcessedDate 00:19:01 — a four-hour offset, consistently, across every request examined.

Warning Filtering both tables on one time window silently drops rows, and near midnight it can miss an entire day. Convert before comparing.

2. SuccessProcessedCount undercounts

It usually equals the audit row count, but not always, and it is never higher. Count ArchiveAudit rows per ArchiveRequestUID when the number has to be right.

3. An empty archive still reports Success and still stamps the workspace

Workspaces with no content complete with SuccessProcessedCount = 0, zero audit rows, and Status = Success — yet the workspace was stamped Archived = 1 with that request's UID.

Warning Archived = 1 does not mean anything was archived. Do not build a storage-reclamation report on that column alone.

4. A live archive rule re-archives whatever you restore

The archive rule, if enabled, will re-fire on each poll. Disable the archive rule before restoring anything it matches.

5. Archiving works with no registered ArchiveLocation

ArchiveLocations can be empty and archiving still succeeds, writing to the path in FilesStorage in appsettings.json. A rule may leave ArchiveLocationId NULL. Do not assume an empty ArchiveLocations table means Archive is unconfigured.