-
Story
-
Resolution: Done
-
Blocker
-
None
-
None
-
True
-
-
True
-
BIZ-629 - ELS add on for concurrent (non-pay-as-you-go) RHEL offerings
-
-
In order to retry messages that failed to send to the marketplaces, we need a new internal api to trigger sending the billable_usage kafka messages again. A cron job is also required to trigger the process.
Swatch-tally-service will get a new internal API for this initiating this:
Billable Usage stuff is bundled as part of swatch-tally, but is kind of treated as its own thing (eventually to become its own service), so it has its own API schema that should be updated instead of the internal-tally one (internal-billing-api-spec.yaml)-> This was done as part ofSWATCH-2103Needs PSK for auth-> This was done as part ofSWATCH-2103- Include an optional timestamp query param (as_of) to enable testing, without timestamp, assume now()
- Query billable_usage_remittance for retry_after > as_of (and non_null)
- Produce kafka message onto platform.billable_usage again
- We don’t need any additional information here
- Clear retry_after column in the table
AC:
- business logic for new internal API filled out that resends billable_usage kafka messages where billable_usage.retry_after < after_on.
- cron job to call the api every 1 hr
Cronjob
- This happens to identify the billable_usage_remittance records that are ready to be retried. Retry_after < now()
- Swatch-tally ClowdApp will get a cron job definition
- Every 1hr
- Cronjob is calling POST endpoint, /internal/rpc/remittance/processRetries (see linked card for API definition)
- GET /internal/remittance/accountRemittances will show the retry_after field . (For QE, internal_api_account_remittance() in mqe-tools hits that end point)
- is blocked by
-
SWATCH-2100 Process dead letter billable usages messages
- Closed
-
SWATCH-2103 Schema updates for enabling retry remittance
- Closed