-
Notifications
You must be signed in to change notification settings - Fork 2
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
MS-438 Prevent invalid person creation event #708
MS-438 Prevent invalid person creation event #708
Conversation
fingerprintCaptureBiometricsEvents, | ||
faceSamples, | ||
fingerprintSamples | ||
) | ||
if (personCreationEvent.hasBiometricData()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we log an error in the opposite case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could, but I am pretty sceptical that anyone will ever look into it.
@@ -70,10 +60,7 @@ internal class CreatePersonEventUseCaseTest { | |||
|
|||
@Test | |||
fun `Does not create event if no biometric data`() = runTest { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need more tests to cover the case that is prevented with this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue is prevented by removing the repo and only using the step result data. I think the current tests cover that; IIRC, there are some extra checks in places where the data is added to step results.
d61e99e
to
a2441aa
Compare
a2441aa
to
3ada1ef
Compare
3ada1ef
to
20285c3
Compare
|
For historical reasons, the "PersonCreated" event data was collected as a combination of capture event IDs from the events in the database and captured templates in orchestrator step results.
In some erroneous edge cases, the capture data in step results and the database events might not match. Most likely, it was when one session was abruptly stopped, and another took its place (but that has to be proven). In any case, such mismatch causes invalid "PersonCreation" - one or more modalities do not have matching sets of capture reference IDs and event IDs.
This change ensures that the "CreatePerson" event has the correct sets of IDs since all the info comes only from step results. This does not address the edge case itself, but it at least makes it easier to recover the data.
Note: IMO, the change, while relatively small, can have some unintended effects. Therefore, depending on the urgency, it should be considered only as part of the next hotfix or major release cycle.