perun icon indicating copy to clipboard operation
perun copied to clipboard

fix(registrar): fix duplicate notifications

Open cuadradek opened this issue 3 years ago • 1 comments

  • Two duplicate group notifications were sent to group managers when a user submitted a group application in the following scenario:
  1. first the user submitted an application to the group's VO, which was auto-approved
  2. then he submitted the group application in less than X seconds
  • The reason is that after the VO application was approved, a new thread was created which slept for 5 seconds and then validated the member in VO and handled the user's group applications - sent notifications to the group's managers. If a group application was submitted in this time window (5 seconds + validation time) an APP_CREATED_VO_ADMIN notification was sent both in this method and in the second step - submitting the group application.
  • #3694 was a quick-fix which removed the thread's sleep, but there was still a big enough time window when this bug could happen.
  • Now, a new table created_app_notifications_sent is introduced to save the information whether APP_CREATED_VO_ADMIN notification was already sent.
  • The notification is sent always in the second step (submitting group application) if the user has a required state.
  • The notification is sent in the first step only if it wasn't sent yet and the user has a required state. There is no need for an additional synchronization (like checking if it is being sent in a concurrent thread), because the first step sends the notification only for committed applications, and they are committed together with information whether the notification was sent.

BREAKING CHANGE: update DB

cuadradek avatar Oct 19 '22 16:10 cuadradek

Couldn't there be a case when the VO application is in the approval process but at the same time the group application is in the submitting process, therefore, no email is sent?

Good question. The email is not sent in the group application's submitting process only if the member doesn't exist or doesn't have a VALID or INVALID state. Then the email is not sent, and the group application is committed to the DB. Meanwhile, the approval process of the VO application is validating the member and then would send the email ONLY if the group application is already committed in DB.

Therefore, I believe there is a very short time window when no email would be sent:

  • member validation in the VO process finished right after the Group process would decide that it wouldn't send a notification
  • VO process then wouldn't see the group application because it is not committed in DB yet

So, the time window is very tiny, and it could happen already before this PR. Therefore, I would say we don't need to worry about that, even considering the new Registrar is on its way.

cuadradek avatar Oct 21 '22 06:10 cuadradek

:tada: This PR is included in version 19.0.0 :tada:

The release is available on GitHub release

Your semantic-release bot :package::rocket:

github-actions[bot] avatar Nov 04 '22 10:11 github-actions[bot]