Skip to content

read_line propagates serial timeouts as hard errors #7

@nedseb

Description

@nedseb

In src/ui/tab_wireless_stack.rs the read_line helper propagates any error from port.read — including ErrorKind::TimedOut. The current default port timeout is 10 ms (open_port), so any read that doesn't return a byte within 10 ms is reported as a hard error.

The flow only works today because every caller does sleep(1 s) before reading (send_and_read_serial), and the operator firmware always responds well under that budget. But this is fragile:

  • A future operator command that takes longer to respond would intermittently fail.
  • A first-byte gap > 10 ms (e.g. USB scheduling jitter on a busy host) currently doesn't happen but is not architecturally prevented.
  • The webusb reference tool's serial_read_until(delim, timeout) returns null on timeout instead of throwing, and lets the caller distinguish timeout from malformed data. That's the cleaner shape.

Suggested change

Change read_line to Result<Option<String>, String> (or carry an explicit timeout argument as Duration and return Ok(None) when it expires). Update send_and_read_serial and the FUS-upgrade loop in fus_upgrade_cmd to handle the new shape. Reduce reliance on the pre-read sleep(1 s) and instead poll with a real timeout.

Not a bloquant — it works today — but tracked here so we don't forget when serial-side reliability becomes important.

Tracked from the stack_flash review, item #13.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions