ENP SQS Send Message Asynchronously

[EvanParish]

User Story - Business Need

For the work to wrap SMS with ENP we need to replicate the minimally necessary functionality leading up to notification-api's deliver_sms Celery task, then use aiobotocore's send_message to enqueue the Celery object. This will bypass the notification-api ECS service entirely for phone number recipients.

• Sync with Kyle when ticket is picked up.
  • SOLID plan
• Ticket is understood, and QA has been contacted (if the ticket has a QA label).

User Story(ies)

As a backend engineer
I want to prepare an envelope for the deliver_sms Celery task from the API
So that we can work towards the transition to using the FastAPI code

Additional Info and Resources

• aiobotocore repo

Acceptance Criteria

• Needs an SQS layer
• When an sms notification request is made to ENP with a phone number recipient we handle the work done up to the notification-api deliver_sms Celery task
• Uses aiobotocore send_message to enqueue a Celery envelope (see Glue example)
• This work is added to the sprint review slide deck (key win bullet point and demo slide)

QA Considerations

This should result in the same output as the notification-api.

Potential Dependencies

Determine Celery tasks necessary based on incoming request.

Out of Scope

Replacing any deliver_sms functionality.

[EvanParish]

I believe I mostly have the code in place, but I'm still fighting with unit tests for now.

[EvanParish]

I'm not sure if the code I've written so far is going to work as-is. I'd like to pair with someone to get another set of eyes on what I've done so far and see if someone else might have some insights into how to move forward. I'm basically stuck at the moment.

I've tried to make the SQSClient a singleton, but in my testing that seems to be creating an issue with calling the context more than once. I run into this error RuntimeError: cannot reuse already awaited coroutine. The solution may be to just not make that class a singleton, but that would mean recreating the client for every request, which would be much less efficient. I'm hoping there's another solution I'm just not seeing yet.