@emmaspark I'm not 100% sure this is correct, but based on the PostgreSQL logs I captured, here's what I observed:

The trigger fires on the first INSERT of the day, not on duplicates.

Here's the flow in find_or_create_project_daily_statistic:

1. find_by(project_id, date) — SELECT, if row exists → return it, no INSERT, trigger never fires
2. If no row → upsert with ON CONFLICT (project_id, date) DO NOTHING → actual INSERT → trigger fires

So on_duplicate: :skip only protects against a race condition where two concurrent requests try to insert the same row simultaneously. The trigger always fires on the first daily INSERT, where there's no conflict in project_daily_statistics.

The bug: after the table swap in !211916 (merged), project_daily_statistics_archived already contains the row for (project_id, date) (it's the original pre-swap table with all historical data). So the trigger's plain INSERT into _archived hits a UniqueViolation.

TL;DR: a conflict between the swap (!211916 (merged)) which already populated _archived with the row, and the trigger which tries to insert the same row again on the first git fetch of the day.

@gitlab-bot label typebug