This topic was automatically generated from Slack. You can find the original thread here.
Gui Pra : Should I store in this.db hooks that haven’t been successfully deleted and try again on future activate/deactivate invocations?
This topic was automatically generated from Slack. You can find the original thread here.
Gui Pra : Should I store in this.db hooks that haven’t been successfully deleted and try again on future activate/deactivate invocations?
Dylan Sather (Pipedream) : this.db
is scoped to a specific deployed component, so once you delete the component, you’ll no longer be able to access the contents of the DB in other components.
The best suggestion I have for now is to implement a little backoff algorithm to retry failed deletes within the deactivate()
method, if the first attempt fails.
If you see this happening a lot, you could also technically add an HTTP request to a service you own with the details of the failure / # of failed retries at the end of the deactivate()
method, if all attempts fail.
Just thinking out loud. We’re thinking about a better story for error handling in general (e.g. something like a source-specific dead letter queue, where all events that failed for a source would go, such that you could retry them)
Dylan Sather (Pipedream) : Definitely let us know if you have a specific pattern you think would make sense for us to implement here
Gui Pra : Got it, thanks.