-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Courey/update table stream #2781
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2781 +/- ##
========================================
- Coverage 6.08% 6.08% -0.01%
========================================
Files 171 171
Lines 4340 4342 +2
Branches 476 478 +2
========================================
Hits 264 264
- Misses 4074 4075 +1
- Partials 2 3 +1 ☔ View full report in Codecov by Sentry. |
b7b818f
to
4e4a9cb
Compare
This is, indeed, a longstanding pain point. It may be worth investing some effort with helping upstream to add support for table streams: architect/architect#1140 |
This change updates the table-stream to account for the past synonymId when a synonym group is deleted.
Testing
This is very challenging to test. It does not work as expected when using the moderator interface locally because table-streams are not supported locally.
I tested it by running the event via the invoker.
The challenge with this method is that I don't think it takes into account the state of dynamodb. This means that during testing with the invoker, the original dynamodb record is still in dynamo. This breaks the functionality for the table-stream because it is checking to make sure nothing still exists in the original synonymId's group. But if the record in dynamodb is not updated, that check will find the existing record and skip the delete.
I added in this line to work around that:
filter((synonym) => synonym.eventId != eventId)
It feels a little odd because in order to trigger this table-stream that original record should have changed already. If I understand correctly, the order of operations is the dynamodb change is made which then triggers the table-stream. So that record should not exist with that synonymId in dynamo when this runs.
It shouldn't hurt to have that filter on there, but I'm unsure if it's necessary because of limitations in local testing.
This is the result of running a modifiy:
EDITED TO ADD:
I'd like to explain the updates so everyone is clear on the cases involved.
originally the synonyms were deleted if everything was removed and when a synonym was removed from a group, no new synonym was created. We changed this when we made it so that every eventId has a synonym record and I didn't update the table sync.
code walk through
cases:
here is a breakdown of the code for the handler:
the updated or new synonym comes through. We get any other dynamo records that belong in the group
here I am checking to see if there is an existing opensearch record for that eventId. This is because in the update for dynamo, the eventId doesn't change, but the synonymId does. There is nothing retaining the knowledge of if there was a previous group involved in this update and what that previous synonymId would be. So to get that, we have to look at opensearch to see if there is an existing record for this eventId
If there is a previous synonymId, it is stored in the previousSynonym variable. That is used to determine if we need to get the members of that previous group. If there was a previous synonymId involved, we look to see if there are other members of the group left. We do this because we need to update the existing openSearch record from the previous group in addition to updating the current synonym group.
If there is a previous group, and it has no members left, it needs to remove the previous synonym record from opensearch.
If there is a previous group and it still has members, it needs to be updated to remove the current eventId from the opensearch record.
This part is updating the current synonym group. If there are any members in the current group, then the opensearch record is updated with the current members.
If there are no members of the current group (which shouldn't really happen since we create a new synonym record when we update a synonymId on a dynamo record) i left this in so if there were no members of the group it would be removed.
test walk through
I updated the unit tests for this. These kinds of tests are heavily mocked, so the test is only as good as the mock is.
There are only five cases under test here.