fix: атомарный dequeue, двойной ATI, MAX_RETRIES 620ms, ретеншн, фильтр device_id

This commit is contained in:
Repinoid
2026-06-28 11:46:00 +04:00
parent c33bd8e2de
commit 25c8eb20b9
3 changed files with 112 additions and 5 deletions
+14 -5
View File
@@ -192,11 +192,13 @@ def raw_dequeue_cmd():
).fetchone()
if not row:
return "", 204
db.conn.execute(
"UPDATE command_queue SET status='sent', sent_at=datetime('now') WHERE id=?",
cur = db.conn.execute(
"UPDATE command_queue SET status='sent', sent_at=datetime('now') WHERE id=? AND status='pending'",
(row["id"],)
)
db.conn.commit()
if cur.rowcount == 0: # перехватил другой воркер
return "", 204
result = {"seq": row["seq"], "cmd": row["cmd"], "timeout_ms": row["timeout_ms"], "drain_first": bool(row["drain_first"])}
logger.info(f"RawELM: dequeued #{row['seq']}{row['cmd']}")
return jsonify(result)
@@ -257,15 +259,22 @@ def raw_get_response():
@bp.route("/api/v1/elm/raw/status", methods=["GET"])
def raw_status():
"""Copilot: статус устройства."""
device_id = request.args.get("device_id", "unknown")
with Database() as db:
# Чистка старых записей (старше 1 дня)
db.conn.execute(
"DELETE FROM command_queue WHERE responded_at < datetime('now', '-1 day')"
)
db.conn.commit()
last = db.conn.execute(
"SELECT seq, status FROM command_queue ORDER BY id DESC LIMIT 1"
"SELECT seq, status FROM command_queue WHERE device_id=? ORDER BY id DESC LIMIT 1",
(device_id,)
).fetchone()
pending = db.conn.execute(
"SELECT COUNT(*) FROM command_queue WHERE status='pending'"
"SELECT COUNT(*) FROM command_queue WHERE device_id=? AND status='pending'", (device_id,)
).fetchone()[0]
total = db.conn.execute(
"SELECT COUNT(*) FROM command_queue WHERE status='done'"
"SELECT COUNT(*) FROM command_queue WHERE device_id=? AND status='done'", (device_id,)
).fetchone()[0]
return jsonify({
"device_ready": last is not None,
@@ -0,0 +1,67 @@
# Opus — переанализ фаз 06 (28.06.2026)
Запрос: doc/opus-recheck-request-2026-06-28.md
---
## Вердикт
**Можно запускать на реальном ELM327 v1.5** для стендовых тестов с одним телефоном.
Логика протокола корректна. Один баг очереди надо закрыть до перехода на `gunicorn -w 4`.
---
## 1. ElmActor.kt — корректен, deadlock нет ✅
`init()` сабмитит `elm.init()` один раз и ждёт `.get(30s)`. Внутри `elm.init()` вызывает `elm.sendCommand("ATI")` прямым вызовом (не через `executor.submit`), то есть на том же потоке actor'а — рекурсивной постановки в очередь нет → deadlock невозможен. `isClone()` читает `@Volatile` поле напрямую — видимость корректна.
**Замечание (low):** при таймауте `.get(30, SECONDS)` Future не отменяется — задача `elm.init()` продолжает крутиться на executor'е, и следующий `send()` встанет за ней в очередь. Худший случай init по сумме `tryRead` ≈ 23с (ATSP0 один даёт до 10с) — близко к лимиту 30с. Рекомендация: `future.cancel(true)` в `catch(TimeoutException)` либо поднять лимит до 45с.
---
## 2. ElmProtocol.kt (raw) — порядок init верный, но есть двойной ATI ⚠️
Канонический порядок правильный: `ATE0→ATL0→ATS0→ATI→detectClone→[ATST96|ATAT1]→ATSP0`. Эхо выключается первым. Обработка двойного ответа ATWS корректна во всех ветках recovery/STOPPED/BUS ERROR.
Проблемы:
- **Двойной ATI (medium):** первый `write("ATI"); tryRead; drainInput()` бесполезен. Затем ещё раз `sendCommand("ATI")`. Python-версия сделана правильно (один `_exec("ATI")`).
- **MAX_RETRIES=6 даёт потолок 600мс, не 2000 (medium):** 6 шагов по +20 = 600мс. Если медленный ЭБУ требует >600мс — всё равно ошибка. Комментарий вводит в заблуждение.
- **exec() не перешлёт команду на ретрае:** пишет `cmd` один раз, при таймауте только перечитывает буфер. Для ELM штатно, но при реальном `NO DATA` повторное чтение не поможет.
---
## 3. raw_elm.py — SQLite-очередь: dequeue НЕ атомарен ❌ (главное)
`GET /api/v1/elm/raw/cmd` делает два отдельных стейтмента без guard'а. При `-w 4` два воркера могут выбрать одну строку → команда уйдёт на ELM дважды.
**Фикс:** `UPDATE ... SET status='sent' WHERE id=? AND status='pending'` + проверка `rowcount == 0`.
Прочие замечания:
- **Рост таблицы:** `command_queue` не чистится (старый код держал 500). Добавить `DELETE WHERE responded_at < datetime('now','-1 day')`.
- **`device_id="unknown"`:** несколько телефонов сольются в одну очередь.
- **`GET /response`:** при всплеске может вернуть ответ не на запрошенную команду (для пошагового relay'я ок).
---
## 4. Python protocol.py — паритет с Kotlin ✅
Тот же порядок, один ATI, ATST96 для клона, `try_read(500)` как drain после каждой AT-команды.
---
## 5. Безопасность (фаза 0) ✅
`api_key → env LLM_API_KEY`. Проверить что старый ключ отозван у провайдера.
---
## Итоговый список к исправлению (по приоритету)
1.**Атомарный dequeue** — guard `AND status='pending'` + `rowcount`
2. ⚠️ **Двойной ATI** в `ElmProtocol.kt init()` — убрать первый `write("ATI")`
3. ⚠️ **MAX_RETRIES/комментарий** — потолок 600мс, не 2000
4. **Ретеншн** `command_queue` + фильтрация `device_id`
5. **Отмена Future** при таймауте init в `ElmActor`
6. **Отозвать старый LLM-ключ** у провайдера
Пункты 2–5 не блокируют стендовый прогон. Dequeue-гонку держать в голове при `-w 4`.
+31
View File
@@ -0,0 +1,31 @@
# Opus — переанализ после фаз 0–6
Дата: 2026-06-28
Предыдущий анализ: doc/history/opus-plan-analysis-2026-06-28.md
## Что изменилось
Твой план из 6 фаз реализован в ветке `opus-fixes`. Изменённые файлы:
### Android (:raw — тестовый модуль, пакет ru.elmer.raw)
- `/home/naeel/elmer/android/raw/src/main/java/ru/elmer/raw/ElmProtocol.kt` — канонический init (ATE0→ATL0→ATS0→ATI→detectClone→ветвл→ATSP0), ATST96 для клонов, MAX_RETRIES=6, @Volatile state, drain после sendCommand, handle STOPPED/NO DATA/UNABLE
- `/home/naeel/elmer/android/raw/src/main/java/ru/elmer/raw/ElmActor.kt` — single-thread executor вокруг ElmProtocol (новый файл)
- `/home/naeel/elmer/android/raw/src/main/java/ru/elmer/raw/RawRelayService.kt` — переведён на ElmActor
### Сервер (Python)
- `/home/naeel/elmer/obd/protocol.py` — канонический init (тот же порядок, clone detect, drain после send)
- `/home/naeel/elmer/api/raw_elm.py` — полная переработка: SQLite command_queue вместо глобальных переменных (gunicorn-safe, -w 4)
- `/home/naeel/elmer/api/db.py` — таблица command_queue
- `/home/naeel/elmer/api/scripts.py` — build_dynamic_script: 6 PID, interval_ms 1200
- `/home/naeel/elmer/config.yaml` — api_key → env LLM_API_KEY (безопасность)
### НЕ тронуто
- `:app` модуль (ru.elmer.client) — весь старый код без изменений
## Что нужно
1. **Валидация** — нет ли новых ошибок, противоречий, race conditions в новом коде
2. **ElmActor.kt** — корректна ли реализация single-thread executor? Нет ли deadlock при init()?
3. **ElmProtocol.kt (raw)** — правильный ли порядок init? Корректна ли обработка двойного ответа ATWS?
4. **raw_elm.py** — корректна ли SQLite-очередь? Атомарен ли dequeue?
5. **Общая оценка** — можно ли с этим кодом запускать тесты на реальном ELM327 v1.5?