Skip to content

Conversation

samvrlewis
Copy link
Contributor

Based on some feedback from Stefan:

Suggestion: when the timeout error is shown, can we append with text "Ensure SBP FILEIO messages 163, 168,169,170,171,173 and 4098 are enabled." ?

Even better would be to say what exact message is missing (like ID 170 for directory list)

  • Update read to timeout if no messages are received
  • Fix a small bug with write which meant it never actually timed out
  • Add hints in timeout messages to tell users what messages they may
    need to enable in order to not have timeouts on the fileio commands.
    This is especially useful for MSG_FILEIO_READ_DIR_RESP which isn't
    enabled to be output by default.

- Update `read` to timeout if no messages are received
- Fix a small bug with `write` which meant it never actually timed out
- Add hints in timeout messages to tell users what messages they may
  need to enable in order to not have timeouts on the fileio commands.
  This is especially useful for MSG_FILEIO_READ_DIR_RESP which isn't
  enabled to be output by default.
@samvrlewis samvrlewis requested review from a team and notoriaga February 8, 2022 23:20
if let Some(req) = guard.get_mut(&seq) {
req.retries += 1;
trace!("retry {} times {}", req.message.sequence, req.retries);
if req.retries >= MAX_RETRIES {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a huge deal but this takes ~30 seconds to time out if 171 isn't enabled. Would it be unwise to lower MAX_RETRIES?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the timeout duration and max retries where taken from the old console. Doesn't mean we shouldn't change it though, it does seem like a while

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we'd need to retest on a lossy/ slow serial connection if we want to adjust these parameters. We could mitigate the bad user experience by displaying a message after a shorter time (like ten seconds) -- something like "still waiting for READ_DIR message..."

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will leave it for now then, I think it's probably a rare case that the message isn't enabled as it is enabled by default.

},
recv(channel::tick(FILE_IO_TIMEOUT)) -> _ => {
self.link.unregister(key);
bail!("Timed out waiting for file read response. Ensure SBP FILEIO message 163 (MSG_FILEIO_READ_RESP) is enabled.");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

small nit you could use MsgFileioReadResp::MESSAGE_NAME/MsgFileioReadResp::MESSAGE_TYPE etc. for all these warnings

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah good call, have updated

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants