You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If there's a temporary (very short-lived) issue communicating with Pebble, then we generally recommend that charms retry a small number of times (with appropriate pauses between attempts) rather than defer(), return, or error out.
Rather than having every charm implement a retry mechanism, we could add this as an option to the various Container methods (but not the underlying Pebble class), so that we handle this transparently for users.
We'd need to consider when retrying is/is not appropriate, as well as what the retry pattern should be.
Per Madrid discussion, this still seems like a reasonable idea, but needs a bit more charm research and a proof of concept to validate it. And do we want to do it on every method, or just the read/GET/non-mutating ones?
If there's a temporary (very short-lived) issue communicating with Pebble, then we generally recommend that charms retry a small number of times (with appropriate pauses between attempts) rather than
defer()
,return
, or error out.Rather than having every charm implement a retry mechanism, we could add this as an option to the various
Container
methods (but not the underlyingPebble
class), so that we handle this transparently for users.We'd need to consider when retrying is/is not appropriate, as well as what the retry pattern should be.
This Discourse post has more details on the motivation.
The text was updated successfully, but these errors were encountered: