A job only ever has one notification type.
This is the first deploy, where the columns are added and populated.
Next a data migration will happen to populate these new columns for the older jobs that do not have the values set.
Then we stop populating the old columns and remove them.
This refactoring of the table structure will make the queries to the table much easier to handle.
Previous:
assumed discrepancy in stats counts to be related to timeouts
Now:
If discrepancy exists do the math on the notifications for that job to work out counts based on statuses to redo stats.
After three days we timeout the notifications that we have not received a receipt for.
In the same way we bump the failed count to match the job count if there is a descepenecy. We do this after the same period that we do for notifications.
- Looks now for a specific Integrity error, not a generic SQLAlchemy error when checking for an insert failure
- If the update fails post an insert error, then there is an issue so raise an exception so tasks can be retried.
- create_or_update_job_sending_statistics
This will try and update an existing row. if this fails as it hasn't been created, then it will insert a row. If this fails as another process has got there first then it should try and update again.
This is a code version of upset
- update_job_stats_outcome_count
Will update the outcome states. Uses the NOTIFICATION_STATUS_TYPES_FAILED to determine if the notification failed.
Any thing in DELIVERED will be marked as delivered. Statues not in the FAILED array or delivered provoke no update to the table.
