Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this change?
Perform upgrade to Play 2.9.
Ideally we want to be on Play 3.0, but that upgrade swaps Play's internals from using Akka to Pekko. We also have direct usages of Akka in our project, and while we could go to Play 3.0 and continue to run an Akka actor system to support those, it'd be nicest if we could swap both simultaneously. Stopping at 2.9 offers a nice stepping point where we can investigate that option, and also a spot to perform the Java 11 -> 17 upgrade too.
While testing locally I discovered that #4360 had quietly broken Thrall's ability to read the message queue while running locally, as the underlying Kinesis client attempts to connect with HTTP/2, but localstack only offers HTTP/1.1. Use some AWS SDK overrides to force it back onto HTTP/1.1 while running locally.
How should a reviewer test this change?
Run locally, deploy to TEST, try some usual Grid functionality.
How can success be measured?
Who should look at this?
Tested? Documented?