Ваш recover() эту ошибку не поймает
In a Go service, recover() can look like a reliable safeguard until a concurrent write to a map ends the process with a fatal error: concurrent map writes. Some races pass unnoticed and lead to data loss without any error in the logs. The article explains why recover() does not help in these cases, how to detect the problem with -race, and which synchronization method to choose for a shared map.
В Go‑сервисе recover() может выглядеть надёжной страховкой, пока конкурентная запись в map не завершает процесс через fatal error: concurrent map writes . При этом часть гонок проходит незаметно и приводит к потере данных без единой ошибки в логах. В статье разбираемся, почему recover() не спасает в таких ситуациях, как обнаружить проблему с помощью -race и какой способ синхронизации выбрать для общей map . Разобрать проблему