Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remote end robustness #44

Open
jkva opened this issue Nov 28, 2022 · 1 comment
Open

Remote end robustness #44

jkva opened this issue Nov 28, 2022 · 1 comment
Labels
question Further information is requested

Comments

@jkva
Copy link
Collaborator

jkva commented Nov 28, 2022

Currently the spec does not include details about how to handle problem events. This issue is intended as a starting point to more thoroughly define how these should be addressed. The list of items as written below is not meant to be exhaustive.

Session creation or command timeout

  • Should timeout configuration be available through command parameters, similarly to how this is addressed within the WebDriver protocol?

Unexpected remote end connection drop

  • Should the existing session be retained, and if so — for how long?
  • Should there be an automatic attempt at recovery?
  • In case of session recovery, there be a re-transmit of any missed information since the connection dropped?

Unexpected AT error

  • Should this communicate an error event, or should the middleware handle this case (for example by retrying, or by restarting the AT...)? This might be implementation-dependent.
@jugglinmike
Copy link
Contributor

Session creation or command timeout

  • Should timeout configuration be available through command parameters, similarly to how this is addressed within the WebDriver protocol?

The three configurable "timeout" values available in WebDriver relate to specific operations. That standard doesn't offer any generic protocol-wide timeout.

Are you suggesting that we introduce a configurable "timeout" value for the protocol at large? Or do you think specific ARIA-AT Automation commands warrant such a value?

Unexpected remote end connection drop

  • Should the existing session be retained, and if so — for how long?

  • Should there be an automatic attempt at recovery?

  • In case of session recovery, there be a re-transmit of any missed information since the connection dropped?

Is this condition distinct from the one currently described in the "Transport" section?

Unexpected AT error

  • Should this communicate an error event, or should the middleware handle this case (for example by retrying, or by restarting the AT...)? This might be implementation-dependent.

Can you share examples of the kinds of errors that might motivate an "error" event?

@lolaodelola lolaodelola added Deprioritised Work that is deprioritised for now question Further information is requested and removed Deprioritised Work that is deprioritised for now labels Jan 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants