Flaky test: TestUploadEmit_ArtifactNewToRepositoryAndNamespace_MovesAllFourCounters reads namespace_statistics as 0 after a clean drain

internal/format/maven.TestUploadEmit_ArtifactNewToRepositoryAndNamespace_MovesAllFourCounters failed the test:integration: [POSTGRES, 17] job on a tree that does not touch the code under test. A retry of the same job passed.

This is one observation, not a rate. No frequency is measured here. This issue exists so that the next run to meet this failure retries against a record, instead of deciding alone whether the failure is real.

What failed

Pipeline 2783492852, job 16055339089, on !1870 (merged) at head 21ac5da40.

Two assertions failed, and both are the namespace pair:

upload_emit_test.go	Assertion	Expected	Actual
485	namespace_statistics.components_count after the drain	1	0
486	namespace_statistics.deduplicated_size_bytes after the drain	153	0

The job ran the suite twice, at 19:52:04Z and at 20:05:40Z, and the same two assertions failed both times. Each run reported DONE 20607 tests, 27 skipped, 1 failure.

What did not fail

The repository pair at lines 475 and 476 passed. Neither line appears anywhere in the job log, and the file references in that log are exactly 485, 486 and 517.

Both require.NoError calls in emitEnv.drain passed, at upload_emit_test.go:422. The namespace-scoped chunk worker returned no error and the two namespace columns stayed at 0.

A lead, not a diagnosis. The repository-scoped chunk moved its two columns in the same drain call, from the same emits, in the same transaction window. That narrows the fault to the namespace-scoped chunk path in internal/accounting rather than to the maven emit path or to the upload handler. Both workers get TickAt: time.Now(), which is a value that differs between the two calls.

Why this is not the branch under test

• !1870 (merged) touches no file under internal/format/maven, at any commit.
• The one commit between the last fully green pipeline and this red one is 21ac5da40, which changes comments and documentation only.
• Pipeline 2783416386 on the immediately preceding head 8831c09cc was fully green, and it ran this same job on PostgreSQL 17.
• The PostgreSQL 16 and PostgreSQL 18 legs of the red pipeline ran the same suite on the same tree and both passed.
• Pipeline 2782938622 on main at the merge base 12859d888 is green.
• go test -count=3 -tags=integration -run 'TestUploadEmit_ArtifactNewToRepositoryAndNamespace_MovesAllFourCounters' ./internal/format/maven/ passes locally.
• The retry, job 16055470896, passed in 721.6 s.

What is open

The mechanism is unknown. One PostgreSQL leg of three failed while the other two passed on one tree, and that pattern fits contention or a timing window rather than a defect in the code under test. Nobody has reproduced the failure on demand.

How the observation was made

An automated /smurfit run met this failure while driving !1870 (merged) to a merge-ready state. It retried the job, and the retry is what closed the pipeline. Every figure above is read from the job log and the API rather than relayed.