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

Aperta
  • Qualcosa non va?
#201 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python
Ambito
backend, testing, tooling

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Python
Stelle
144
Fork
96
Merge medio
3g 17h
PR unite (30g)
6

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di BluePilotDev/bluepilot

Tutte le issue di BluePilotDev/bluepilot

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.