-
Notifications
You must be signed in to change notification settings - Fork 46
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
Purge Outgoing Webhooks events and deliveries data #229
base: main
Are you sure you want to change the base?
Purge Outgoing Webhooks events and deliveries data #229
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bhumi1102 Overall this looks great but I think we should add an example of how to call the job to the docs.
@@ -27,6 +27,8 @@ payment.generate_webhook(:succeeded) | |||
## Delivery | |||
Webhooks are delivered asyncronously in a background job by default. If the resulting HTTP request results in a status code other than those in the 2XX series, it will be considered a failed attempt and delivery will be reattempted a number of times. | |||
|
|||
All of the delivery attempts and events are stored in the database. There is a background job to purge records in these tables as they can grow large in size over time. You can schedule this job to purge records older than 90 days by default. | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add an example of at least how to call the job here, just so people don't have to go hunting for it?
Leaving this for @andrewculver since it relates to outgoing webhooks. |
closes #205
Goal of this PR is to add a background job that will purge data in the
webhooks_outgoing_events
,webhooks_outgoing_deliveries
, andwebhooks_outgoing_delivery_attempts
tables with acreated_at
older than 90 days by default.We are assuming that the bullet train user will schedule this background job using whatever means they prefer to use in their application (i.e. leaving this up to the user and not adding some cron scheduling gem like
whenever
at this point. We can do this if we decide)Testing Done:
Tested the background job with locally running sidekiq server and calling the
Webhooks::Outgoing::PurgeJob.perform()
with different number of days. Confirmed that the correct records are deleted from the database after the job is run. And that records that are not older than X days still remain in the table and are not deleted.