Skip to content

process_sms_client_response: accept & log delivery_iso_timestamp & receipt_iso_timestamp#4783

Open
risicle wants to merge 1 commit intomainfrom
ris-receipt-delivery-time-celery
Open

process_sms_client_response: accept & log delivery_iso_timestamp & receipt_iso_timestamp#4783
risicle wants to merge 1 commit intomainfrom
ris-receipt-delivery-time-celery

Conversation

@risicle
Copy link
Member

@risicle risicle commented Mar 18, 2026

Optional with a default of None, these timestamps can be provided by the endpoint responsible for putting the task on the queue.

At some point we may want to do something better with these, e.g. produce a metric or save the information to the database, but for now this is better than nothing and the log message will give us a bit of a paper trail for individual notifications.

Deliberately feeding the timestamps through the queue rather than doing something with them in the callback handler because the callback handler doesn't currently do any explicit logging of its own and we don't want to add a new log message on the account of this - it's yet to be seen how reliable or useful the "delivery time" reported by sms providers even is.

--

This is the first PR of 2, the second of which will actually start providing the arguments in the callback handler. This PR has to be merged & released first though to ensure a smooth rollout.

…ceipt_iso_timestamp args

optional with a default of None, these timestamps can be provided
by the endpoint responsible for putting the task on the queue.

at some point we may want to do something better with these, e.g.
produce a metric or save the information to the database, but for
now this is better than nothing and the log message will give us a
bit of a paper trail for individual notifications.

deliberately feeding the timestamps through the queue rather than
doing something with them in the callback handler because the
callback handler doesn't currently do any explicit logging of its
own and we don't want to add a new log message on the account of
this - it's yet to be seen how reliable or useful the "delivery
time" reported by sms providers even is.
@risicle risicle marked this pull request as ready for review March 18, 2026 15:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant