Недетерминированное восстановление состояния после паники в конкурентных обработчиках запросов #2

New Issue

2026-08-17T21:14:22Z

gvsafronov commented

2026-08-17 21:14:22 +00:00

Проблема

Структура PanicRecoveryManager в panic_recovery.go перехватывает паники и пытается перезапустить горутины. Однако при возникновении паники контекст выполнения теряется, что приводит к ряду проблем. Операции, обрабатываемые в момент паники, не завершаются, что может оставить клиентов в ожидании ответа бесконечно долго.
Если паника возникает во время операции записи, данные могут остаться в промежуточном состоянии без надлежащей обработки ошибок или отката. Восстановление является недетерминированным и зависит от точного момента возникновения паники, что делает поведение системы непредсказуемым.

Архитектурная проблема

Как гарантировать детерминированное восстановление состояния после паники в многопоточной среде с активными конкурентными запросами?

Предлагаемые направления исследований

Восстановление на основе контрольных точек — периодическое сохранение состояния операции с помощью контрольных точек, позволяющее выполнять откат к последнему согласованному состоянию
Идемпотентные обработчики — проектирование всех обработчиков операций как идемпотентных, что позволяет безопасно повторять их после паники
Воспроизведение журнала транзакций — сохранение операций в журнале транзакций и их воспроизведение после восстановления.
Сохранение контекста — сохранение контекста выполнения (идентификатор запроса, параметры, частичное состояние) перед выполнением рискованных операций
Атомарность отказов — обеспечение выполнения операций либо полностью, либо с полным откатом (семантика «всё или ничего»)
Контролируемый мониторинг — использование процессов-наблюдателей (watchdog), которые отслеживают состояние горутин и координируют восстановление

Соответствующие файлы с исходным кодом

internal/cluster/panic_recovery.go
internal/cluster/node.go (handleNodeRequest, строки 450–500)
internal/cluster/raft_coordinator.go (использование PanicRecoveryManager)

Проблема Структура PanicRecoveryManager в panic_recovery.go перехватывает паники и пытается перезапустить горутины. Однако при возникновении паники контекст выполнения теряется, что приводит к ряду проблем. Операции, обрабатываемые в момент паники, не завершаются, что может оставить клиентов в ожидании ответа бесконечно долго. Если паника возникает во время операции записи, данные могут остаться в промежуточном состоянии без надлежащей обработки ошибок или отката. Восстановление является недетерминированным и зависит от точного момента возникновения паники, что делает поведение системы непредсказуемым. **Архитектурная проблема** Как гарантировать детерминированное восстановление состояния после паники в многопоточной среде с активными конкурентными запросами? **Предлагаемые направления исследований** Восстановление на основе контрольных точек — периодическое сохранение состояния операции с помощью контрольных точек, позволяющее выполнять откат к последнему согласованному состоянию Идемпотентные обработчики — проектирование всех обработчиков операций как идемпотентных, что позволяет безопасно повторять их после паники Воспроизведение журнала транзакций — сохранение операций в журнале транзакций и их воспроизведение после восстановления. Сохранение контекста — сохранение контекста выполнения (идентификатор запроса, параметры, частичное состояние) перед выполнением рискованных операций Атомарность отказов — обеспечение выполнения операций либо полностью, либо с полным откатом (семантика «всё или ничего») Контролируемый мониторинг — использование процессов-наблюдателей (watchdog), которые отслеживают состояние горутин и координируют восстановление **Соответствующие файлы с исходным кодом** internal/cluster/panic_recovery.go internal/cluster/node.go (handleNodeRequest, строки 450–500) internal/cluster/raft_coordinator.go (использование PanicRecoveryManager)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: gvsafronov/futriix#2