From ec795b4764f3be4913bbfa83b65498ed16ff01e7 Mon Sep 17 00:00:00 2001 From: evgeny Date: Mon, 26 Oct 2026 15:01:59 +0100 Subject: [PATCH] Explain false radio mesh failure and preserve rebase audit --- doc/call_audit_findings.txt | 68 +++++++++++++++++++++++++++++++++++++ doc/tasks.md | 17 +++++----- 2 files changed, 77 insertions(+), 8 deletions(-) diff --git a/doc/call_audit_findings.txt b/doc/call_audit_findings.txt index 1ec98143..fc7157c8 100644 --- a/doc/call_audit_findings.txt +++ b/doc/call_audit_findings.txt @@ -473,3 +473,71 @@ PASS (8388608 байт), check-load8/8 PASS (134217728 байт); общий exi только там, запуск от user; IPv6 хоста остаётся отключён. Аппаратный GUI/Android, ASAN/UBSan/LSan не запускались. Аудит headless/платформ/видео ещё не завершён; call остаётся0[V]/10[~]/11[ ], архитектурный документ[~]. Push не выполнялся. + +9. Проверка test_radio_mesh: место дедупликации зависит от порядка прихода — 26.10.2026 + +Вывод: dupC>0 не является инвариантом diamond. Дедупликация успешно срабатывает +на другом узле, а тест выдаёт ложный FAIL. Подтверждено наблюдением настоящих +raw ETCP отправок/приёма до radio_recv; production radio/uasync не менялись. + +В tests/test_radio_mesh.c добавлены диагностические снимки фаз/узлов/рёбер, +а в Unix-сборке --wrap=etcp_bind/etcp_send. Наблюдатели вызывают реальные функции, +не меняют payload, результат, порядок или владение entry. DEBUG_CATEGORY_DEBUG +явно включена на INFO; события показывают self/peer/src/group/stream/seq/FIN/hops. +Счётчики TX означают переданные etcp_send задачи, RX — вход в raw callback. +Возврат к радио-обработчику и дедупликация остаются настоящими. + +Опция UTUN_TEST_MESH_TAIL оставляет прежний loop работающим ещё500мс после +исходного P_DONE. Снимок dupC до хвоста сохраняется для итогового вердикта, +поэтому диагностический хвост не превращает старый FAIL в PASS. Обычный режим +сохраняет прежнее чтение счётчика после выхода из uasync_mainloop. +Таймер хвоста исполняется в работающем loop, без sleep/повторного запуска +остановленного mainloop; флаг stop автоматически не сбрасывается. + +Нативная сборка ./build.sh --no-gui -j4 и цель make -C tests test_radio_mesh PASS: +/tmp/radio-mesh-audit-build.log, /tmp/radio-mesh-audit-target-build.log. +Запущен один обычный тест и16 с хвостом, по8 параллельно. Итог16 PASS/1 FAIL. +Сводка /tmp/radio-mesh-audit-runs.log, подробные ...-run-00.log..16.log. +Проверка всех логов /tmp/radio-mesh-audit-evidence.log сверяет кадры/FIN/seq, +порядок raw RX, счётчики рёбер и отсутствие runtime ERROR/неожиданных WARN. + +Полный разбор воспроизведённого FAIL: /tmp/radio-mesh-audit-run-01.log. +1) В14:54:49.182 A отправляет seq0..5 обоим B и D; seq5 — FIN. +2) D принимает их и пересылает C. В14:54:49.183 C пересылает их B. +3) B принимает все6 от C в14:54:49.183607..183631, впервые видит ключи + (src=A,stream=64106,seq0..5), доставляет локально5 кадров и FIN. +4) Прямые A→B приходят лишь в14:54:49.185416..185444. radio_seen_dup + возвращает1, radio_recv увеличивает dupB и выходит ДО дальнейшего flood. + Поэтому B→C TX0, C←B RX0, dupB6 и dupC0. +5) В P_DONE все B/D/C имеют frames5/FIN1/seq_ok1. Через500мс показатели + остаются теми же: это не доказанный случай раннего завершения ожидания C. + +Код согласован с логом: radio_seen_dup ведёт общий для узла кэш src/stream/seq, +независимо от соседа/хопов. Первый путь выигрывает; последующий дубликат +отбрасывается до radio_flood. Оба A→B и A→D существовали и передали пакет; +второй путь до C не обязан завершиться, если пути уже сошлись раньше на B. +Нормальный запуск run00, напротив: B получает A раньше, отправляет C; +C получает обе копии и имеет dupC6. Порядок UDP/dispatch не задан контрактом. + +Предлагаемое исправление теста: ждать полную доставку/FIN и проверять +дедупликацию на допустимом узле B/C/D; закрепить оба порядка прихода. +Не добавлять фиксированную задержку и не ждать только dupC: хвост показал, +что C вообще не получит вторую копию в корректном варианте обхода. +Критерий и production пока не исправлялись; задача остаётся открытой. + +Новый общий check был запущен с диагностическим тестом, но по запросу +пользователя pull/rebase корректно прерван SIGTERM runner до изменения дерева. +Процессы тестов остановлены; /tmp/radio-mesh-audit-full-check.log и ...-netns.log +содержат interrupted143, поэтому полным результатом не считаются. +В этом общем прогоне сам test_radio_mesh прошёл; tests/logs/test_radio_mesh.log. +Санитайзеры и аппаратный GUI/Android в этой проверке не запускались. + +git pull --rebase успешно выполнен на origin/master aea8ca72: перенесены все23 +локальных коммита. Конфликты были только в doc/tasks.md; записи feedback/member +сохранены побайтно, старые call-задачи обновлены до их итоговых состояний. +Исходники локальных изменений сохранены; tests/Makefile.am содержит также новые +upstream member_purge sources. Рабочее дерево после rebase чистое. +Сам radio.c и диагностический тест побайтно совпадают с проверенными до rebase; +новая объединённая версия целиком ещё не собиралась/не тестировалась. +Исторические ID коммитов разделов1–8 относятся к состоянию до rebase; +диагностика после него: c2908a6c/d943c0dd/21af2e0f/ff394c7a. Push не выполнялся. diff --git a/doc/tasks.md b/doc/tasks.md index 0070a857..0c4558f9 100644 --- a/doc/tasks.md +++ b/doc/tasks.md @@ -1142,14 +1142,15 @@ ## Открытые флаки -[ ] **test_radio_mesh: все кадры приняты, но dupC=0 в общем прогоне** — 26.10.2026: - Два `check.sh`:201/202 PASS, единственный отказ — «result ok, но дедупликация не сработала (dupC=0)». - Одиночный запуск того же бинарника с UTUN_TEST_DEBUG=1 PASS; в логе есть dup drop seq0..5 и итоговый dup=6 у C. - Одиночный запуск в таком же IPv6 namespace тоже PASS; окружение само по себе сбой не воспроизвело. - Условие P_WAIT_RX1 проверяет кадры/FIN/порядок, но не ждёт дубликатов перед P_DONE; - это наблюдение по коду, точная причина сбоя ещё не локализована. Нужны состояния/ID узла и фазы в диагностике. - call_audio в test_radio_mesh не линкуется (проверено nm), radio/uasync в текущем исправлении не менялись. - Логи /tmp/call-audio-tx-radio-mesh-{first,repeat,debug,netns}.log. +[ ] **test_radio_mesh: неверное требование дедупликации именно на C** — причина подтверждена 26.10.2026: + После A→D→C→B узел B уже видел кадры; поздние прямые A→B удаляются там как дубли, B→C не отправляется. + Все B/D/C получают ровно5 кадров по порядку и FIN, dupB=6, dupC=0; тест ошибочно считает это отказом. + Диагностический хвост500мс сохраняет dupC=0: простое ожидание C проблему не исправляет. + 17 запусков с наблюдением raw ETCP:16 PASS и один воспроизведённый ложный FAIL; лог полностью разобран. + Исправлять критерий теста: полная доставка/FIN и дедупликация на допустимом узле B/C/D; + закрепить альтернативные порядки прихода. Критерий успеха пока не менялся, production не менялся. + Логи /tmp/radio-mesh-audit-run-01.log, ...-runs.log, ...-evidence.log; отчёт call_audit_findings.txt,раздел9. + Общий check с диагностикой остановлен для запрошенного pull/rebase, нового полного результата нет. [ ] **test_etcp_transport: таймаут восстановления REALITY-сессии** — 18.10.2026: в общем `./check.sh` сценарий `reality=1 simultaneous=0 restart=0` завершился