Дізнався, що
uint64_t time_us = ts.tv_sec * 1000000 + ts.tv_nsec / 1000;
хоч і такий собі генератор псевдовипадкових чисел, але може призвести до веселих моментів.
Так і не дізнався, чий код (ліньки git blame робити) та чому воно досі робило (використовується в "tx resource reservation / scheduler")
Це ще не продакшн, а тести швидше за все проходило через те, що на цільовій машині система при завантаженні ставила як початкову якусь дату-час чи конфігурування, чи збирання системи, потрапляло на щасливий час, коли до збою часу більше, ніж потрібно тестам. А зараз перед релізом в найтлі збільшили кількість пакетів/час проходження тестів, воно й посипалося.
Наступної ночі після мого мерджа гілки з 267-ма зміненими файлами (єдиного у той день мерджа в мастер)…
У яких той шматок і не чіпався, то я вже очами читав все дотичне до проблеми…
p.s. А для тих, хто пише речі на зразок
enum bla_bla_bla_event event;
rc = queue_dequeue(&bla_bla_bla_event_queue, (uintptr_t*)&event);
заготовлене окреме місце або дія (не знаю вже де/що, залежно від релігії того, хто писав код).
Бо потім дуже весело шукати, чого залежно від цільової системи це інший код, ніяк не пов'язаний зі змінною event, або дивно себе поводить, або випадає в panic кількома десятками рядків нижче.