Evaluate: open requests stuck in a non-final status and simulator freeze on piped stdin

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

I maintainer di solito rispondono entro 1 giorno

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
Da chiarire
Stato di attività
Attiva
Stack tecnologico
node.js, php, typescript
Ambito
backend, embedded-iot

Direzione di ricerca

Start by tracing the backend request lifecycle around CompartmentOpenRequest, routes/console.php, and app/Console, then compare it with the timeout in useOpenProgress.ts and stale-command discussion #134. For the simulator, reproduce the documented --interactive case with a simple pipe and inspect its stdin handling; the payload gives no simulator file path. Done means establishing whether either behavior is a real bug and what change, if any, is needed.

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

Descrizione

backend iot client

Two things seen while testing PR #318 on a local stack with the locker simulator. Neither is confirmed as a bug yet, and neither looks caused by that PR. This issue is to evaluate them and decide what, if anything, to do. Split it if they turn out to need separate work.

1. Open requests can stay in a non-final status

Seen: a CompartmentOpenRequest created at 08:44:30 UTC on 2026-10-30 stayed acknowledged and never reached opened, failed or another final status. The simulator had stopped publishing at 08:44:05, and the backend marked the bank offline at 08:45:00.

Found in code: routes/console.php only schedules DetectOfflineLockers, and app/Console has no job that expires open requests. This was a limited search. The app has its own no-response timeout (useOpenProgress.ts), so the phone may recover even if the backend record doesn't.

Not traced: how this request reached acknowledged while the simulator was unresponsive. The simulator was restarted around that time, so a queued command delivered on reconnect is one possibility.

To evaluate:

  • Is a permanently non-final request a real problem, or only cosmetic in the audit trail?
  • Does it block or mislead anything, such as later opens, admin views or the mobile status?
  • Should requested, sent or acknowledged requests expire, and when? Should a bank going offline affect them?
  • If a queued command can be delivered late, how does this align with the stale-command discussion in #134?

2. Simulator froze with --interactive on piped stdin

Seen: the simulator was started like this, so that commands could come from both a FIFO and the terminal:

(tail -f sim.fifo & cat) | pnpm sim --interactive

After about 120 seconds, heartbeats stopped and typed commands got no response. The Node main thread was stuck in anon_pipe_read, and the broker published the Last Will about 90 seconds later. Started with plain pnpm sim on a TTY, the same scenario showed no freeze over a run of 400+ seconds.

Unknown: whether this is a simulator bug or a result of that shell pipeline, which is unusual. It hasn't been reproduced with a simpler pipe.

To evaluate:

  • Does it reproduce with a simple pipe, for example some-command | pnpm sim --interactive?
  • --interactive is documented for non-TTY stdin, so if it reproduces, it should be fixed or the flag's limits documented. It matters mainly for anyone scripting the simulator.

Related

  • #134: rejecting stale open_compartment commands
  • PR #318: where these were observed
Lingua principale
PHP
Stelle
26
Fork
2
Merge medio
2g 19h
PR unite (30g)
10

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

  • Nessun Dockerfile né file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

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 Open-Locker/Open-Locker

Tutte le issue di Open-Locker/Open-Locker

Issue simili

Altre issue su PHP

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.