[Rohithmatham12]

What this changes

• Initializes the per-tenant Thanos shipper before assigning userDB.db in createTSDB.
• Keeps blocksToDelete from observing a partially initialized userTSDB where db is visible but shipper is still being written.
• Leaves the shipped-block cache initialization after the TSDB is fully assigned, preserving the existing behavior.

Why
tsdb.Open installs userDB.blocksToDelete as a callback and can run block reload work concurrently. Previously createTSDB assigned userDB.db before creating userDB.shipper, so the callback could read userDB.shipper while the constructor wrote it. Creating the shipper before making db visible removes that race window without adding locks to the callback path.

Fixes #6413.

Testing

• git diff --check
• GOCACHE=/private/tmp/cortex-go-cache-6413 GOMODCACHE=/private/tmp/cortex-go-mod-cache go test -tags "netgo slicelabels" ./pkg/ingester -run "TestIngester_shipBlocks|TestIngester_dontShipBlocksWhenTenantDeletionMarkerIsPresent|TestIngester_TSDB"
• GOCACHE=/private/tmp/cortex-go-cache-6413-full GOMODCACHE=/private/tmp/cortex-go-mod-cache go test -tags "netgo slicelabels" ./pkg/ingester

[sandy2008]

Thanks for looking at this. The new order closes the "db set but shipper not yet" window, but I don't think it removes the data race from #6413; details inline.

[sandy2008]

Moving this assignment after the shipper changes the order of two plain writes, but it doesn't synchronize them with the reader. tsdb.Open has already started the reload goroutine (BlockReloadInterval is 1m), which calls blocksToDelete and reads u.db and u.shipper without a lock or atomic, so -race still reports this write against the u.db == nil read. I reproduced it with a small probe: a goroutine calling u.blocksToDelete(nil) in a loop while the test assigns u.db = db fails under go test -race with a data race on exactly this pair. Could we publish with synchronization instead, e.g. an atomic.Bool set after db and shipper are assigned and checked at the top of blocksToDelete, and add a -race test for it?

[Rohithmatham12]

Thanks for catching this. I added an atomic publication flag that is stored only after db and shipper are assigned, and blocksToDelete now checks it before reading either field. I also added a concurrent publication test and ran:

go test -race -tags "netgo slicelabels" ./pkg/ingester -run "TestIngester_UserTSDB_BlocksToDelete" -count=1

It passes at 4294d28fbf.