Portal robustness: clock-jump timeout bugs, swallowed exceptions, lost tracebacks (plus a ruff cleanup plan)

Abierto
  • ¿Algo no está bien?
#201 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
backend, testing, tooling

Línea de trabajo

Split the work into the proposed PRs, starting with the timeout and idle-timer sites in bluepilot/backend/core/process_manager.py, video/export.py, core/server_state.py, and utils/power.py, then inspect the listed bare-except and logging sites. Run the pinned ruff, compileall, import smoke test, and existing bluepilot/backend tests; done means each scoped PR has its corresponding behavior or regression coverage and preserves the stated wall-clock timestamp behavior.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

I drive on BluePilot daily and would like to help with code health. I ran the repo's pinned ruff (0.15.16, existing pyproject.toml config) against bp-dev @ e22afa6be. Most of what it reports is cosmetic, but a few findings look like real bugs in the portal. I'm volunteering to fix all of this myself in small PRs. This issue is here so you can object to the approach before I start.

Findings that matter

1. Timeouts and idle timers are computed from wall-clock time (8 uses). The device boots with the wrong clock and jumps when network or GPS time arrives. A deadline that spans that jump fires immediately or never fires.

  • bluepilot/backend/core/process_manager.py:50,58: process wait deadline
  • bluepilot/backend/video/export.py:617,625: export wait deadline
  • bluepilot/backend/core/server_state.py:37,155: uptime
  • bluepilot/backend/utils/power.py:22,75: idle time, which decides when background processing may start

Fix: use time.monotonic() for these 8. The other ~18 time.time() calls (started_at, completed_at, unix_time, cache and file ages) are correct wall-clock timestamps. Each of those will get a # noqa: TID251 with a reason, so the rule still catches a deadline written with time.time() in future.

2. Bare except: (13 uses, 12 in bluepilot/backend). Most silently return a default value (False, 0, 'unknown', port 8088). A bare except: also catches KeyboardInterrupt and SystemExit.

  • network/utils.py:24,32,58,102
  • routes/parsing.py:31
  • routes/preprocessor.py:253
  • routes/scanner.py:140
  • routes/segments.py:72
  • storage/preservation.py:78,139
  • video/export.py:572
  • video/remux.py:84
  • setup_web_routes.py:94

Fix: narrow each to the exceptions the try body can actually raise. I'll use except Exception: where that isn't clear. Defaults stay as they are, with one exception: is_onroad() (see #203).

3. logger.error(...) inside except blocks (49 uses, TRY400). These drop the traceback, which makes Sentry and log reports harder to act on. Fix: logger.exception(...).

The rest (cosmetic)

451 violations in 71 files in total. All but about 10 are in BluePilot-owned code (bluepilot/, selfdrive/ui/bp/), and the Ford _ext files have none. 204 are safe autofixes, of which 123 are whitespace on blank lines. 92 are unused or deprecated imports.

Specs (all target bp-dev, one concern each)

Two bugs turned up while writing these, and they go first:

  • #202: power-save restore and the onroad status broadcast never run (missing argument, TypeError on every monitor run)
  • #203: is_onroad() reads a misspelled param and always returns False on device, so the onroad lockout never engages

Then the original items:

  • #204: monotonic clock for deadlines, idle timer and uptime
  • #205: narrow the bare excepts
  • #206: keep tracebacks (logger.exception), all 49 sites classified
  • #207: dead imports, import probes, and the two tests that can't fail
  • Bulk autofix (whitespace and annotations), limited to files no open PR touches so nobody has to rebase. No spec yet.
  • selfdrive/ui/bp/ cleanup, which I won't start until the sunnypilot sync (bp-sync-skill-07262026) lands, because that sync renames every file there. No spec yet.

Each PR will include compileall output, an import smoke test, the existing bluepilot/backend tests, and new tests for any behavior change. This fits with the CI conversation on Discord, since a lint job can't be made a required check until the code passes it.

If any of this is unwanted, especially the bulk autofix and the ui/bp cleanup, which are purely cosmetic, tell me and I'll drop it.

Edited 2026-09-21: linked the specs, added #202 and #203, and corrected the network/utils.py note. Line 32 is should_server_run(). The driving check is is_onroad() at line 20, covered in #203.

Lenguaje dominante
Python
Estrellas
144
Forks
96
Merge medio
3 d 17 h
PR fusionados (30 d)
6

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de BluePilotDev/bluepilot

Todos los issues de BluePilotDev/bluepilot

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.