RyanChimienti
commented
1 year ago I'm happy to review the general design and code, which looks good. Appears to be a solid simplification.
With that said, I didn't follow the docs and set this up to do integration testing, so I'm relying on your expertise there that this is good. If you'd like an independent person to set it up and test as well for each PR, I can get up to speed and do that, just let me know.
Thanks Brent, that's totally fine. I think the value of the review in this case is just having a second pair of eyes on the code for anything that looks fishy.
Our Amazon Connect integration offers built-in load testing functionality. This PR makes it easier to use and more flexible.
For a high-level view of how the integration works, see the Architecture Overview section of the docs.
Load Testing Background
The general idea is that we load test the integration by putting a single call through Connect, but triggering many integrator sessions for that call. Each session transcribes the full call. From the integrator's perspective, this is the same as handling many different calls, so it reveals to us how the integration will perform under that number of concurrent calls.
These Changes
Before this PR, the contact flow would call the trigger lambda once, which would kick off many integrator sessions. After this PR, the contact flow calls the trigger lambda many times, and the trigger lambda always kicks off exactly one integrator session. This allows us to simplify the trigger lambda, pushing its logic into the contact flow. This is a big improvement because the user has free reign over the contact flow and can adjust the logic to their needs, whereas the trigger lambda can't be as easily updated.
In particular, these changes make it easy to observe the transcripts for just one of the calls during a load test, which gives a qualitative measure of latency under the load in question.