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
The actionqueue handles changes to the actions subsystem. When it successfully performs an action, it marks the action as performed and stores that information. Storing the performed actions allows the control server to safely send down the same action (with the same ID) an unlimited number of times -- the actionqueue will only perform that action if it wasn't able to perform it successfully previously, which implements retries for actions.
We think that this retry mechanism is not sufficient (especially for some of our more important actions like remote uninstall), since it relies on the control server changing the data in the actions subsystem. (E.g., if a remote uninstall action failed to process once, launcher would not retry until it received a new remote uninstall action, or a new notification, etc.)
We would like to update launcher's behavior so that the actionqueue will retry received-but-failed actions proactively, without requiring a prompt from the control server.
Requirements for implementation:
If any action fails, the actionqueue should retry it at a reasonable interval (once an hour?)
The actionqueue should never retry actions that have already been completed successfully
The actionqueue should never retry actions that are expired
The text was updated successfully, but these errors were encountered:
I wonder if just returning an error from func (aq *ActionQueue) Update(data io.Reader) error if any action fails to process would do it? Then the updated data for that subsystem won't be stored, so Update would be called again in 1 minute by the control system, effectively handling the retry for us.
The actionqueue handles changes to the
actions
subsystem. When it successfully performs an action, it marks the action as performed and stores that information. Storing the performed actions allows the control server to safely send down the same action (with the same ID) an unlimited number of times -- the actionqueue will only perform that action if it wasn't able to perform it successfully previously, which implements retries for actions.We think that this retry mechanism is not sufficient (especially for some of our more important actions like remote uninstall), since it relies on the control server changing the data in the
actions
subsystem. (E.g., if a remote uninstall action failed to process once, launcher would not retry until it received a new remote uninstall action, or a new notification, etc.)We would like to update launcher's behavior so that the actionqueue will retry received-but-failed actions proactively, without requiring a prompt from the control server.
Requirements for implementation:
The text was updated successfully, but these errors were encountered: