[brocla]

Why

TestSweepExpiredJobsDeletesOldWorkspaceOnly failed on CI during #32. It shrank job retention to 100 ms and needed "complete the fresh job, then sweep" to finish within that time. On a slow Windows runner it didn't, so the fresh job's workspace was swept.

Underneath was a real bug. The store writes timestamps with RFC3339Nano, which trims trailing zeros, and the expiry queries compare them as text (completed_at < ?). So 10:00:00.5Z sorts before 10:00:00Z, and a job completed half a second after a cutoff counted as expired. In production, with 30-day retention, that's harmless. In millisecond-scale tests it's a second source of random failures. The alert tables already avoid this with a fixed-width format.

Changes

• Store: alertTimeFormat becomes the store-wide timeFormat (nine fixed fraction digits). Every timestamp write uses it, covering jobs, submissions, deliveries and cutoffs. Reads still parse with RFC3339Nano, which accepts both formats, so there's no migration. Old and new rows can misorder only within the same second.
• App: a now clock field with a clock() method, the same pattern as mailgun.Service. The sweep measures retention against it, and jobRetentionPeriod is a constant again.
• Tests:
  • The sweep test sets the clock so the cutoff lands exactly on a boundary taken between the two completions. A slow runner can only widen the margins now.
  • expireEverything moves the clock forward instead of changing the shared retention period.
  • New store tests cover ordering within a second for jobs and for deliveries, plus a check that every timestamp column is stored at a fixed width. All three failed before the fix.

Testing

• Sweep tests: 200 runs, all passing.
• Store expiry tests: 50 runs, all passing.
• go vet ./... and go test ./... pass.

Production behavior is unchanged apart from the sub-second ordering fix, so deploying this can wait for the next scheduled deploy.

🤖 Generated with Claude Code