paul cannon ee33cb1289 satellite/repair: protect concurrent access to statsCollector ... It would appear that we have been making concurrent accesses to statsCollector for a long, long time (we expect there to be multiple calls to `Repair()` at the same time on the same instance of `SegmentRepairer`, up to `config.MaxRepair`, and before this change there was no sort of synchronization guarding accesses to the `statsCollector.stats` map. Refs: https://github.com/storj/storj/issues/6402 Change-Id: I5bcdd13c88913a8d66f6dd906c9037c588960cc9		2023-10-13 09:12:00 -05:00
..
ec.go	satellite/repair: unify repair logic	2023-09-25 09:42:08 -05:00
repairer_test.go	satellite/repair: repair is configurable to work only on included/excluded placements	2023-09-27 14:54:06 +00:00
repairer.go	satellite/repair: repair is configurable to work only on included/excluded placements	2023-09-27 14:54:06 +00:00
segments_test.go	satellite/repair: repair is configurable to work only on included/excluded placements	2023-09-27 14:54:06 +00:00
segments.go	satellite/repair/checker: optimize processing, part 1	2023-10-11 15:50:29 +00:00
stats.go	satellite/repair: protect concurrent access to statsCollector	2023-10-13 09:12:00 -05:00