sigit/sigit.io
7
2
Fork 0
Code Issues 32 Pull Requests 2 Actions Packages Projects 1 Releases Wiki Activity

fix: processing gift wraps and notifications #193

Merged
enes merged 5 commits from notification-debug into staging 2024-09-12 08:27:00 +00:00
Conversation 2 Commits 5 Files Changed 2 +32 -6
enes commented 2024-09-10 11:12:52 +00:00
Member
Copy Link

This change will potentially close multiple issues related to the gift-wrapped events processing (#168, #158). Further testing will be required to confirm before closing each.

The commented-out code causes the race condition during the processing of the gift wraps with sigits.

During the processing we perform checks to see if sigit is outdated. In cases where sigit includes multiple signers it's possible for a signer to receive multiple sigit updates at once (especially noticeable for 3rd, 4th signer). Due to async nature of processing we can have same sigit enter processing flow with different states. Since this code also updates user's app state, which includes uploads to the blossom server it takes time to upload local user state which causes both to check against the stale data and un-updated app state. This results in both sigits being "new" and both proceed to update user state and upload app data. We have no guarantees as in which event will update last, meaning that the final state we end up with could be already stale.

The issue is also complicated due to the fact that we mark the gift wraps as processed and it's impossible to update the state without creating a new gift wrap with correct state and processing it last to overwrite stale state.

This is temporary solution to stop broken sigit states until proper async implementation is ready.

This change will potentially close multiple issues related to the gift-wrapped events processing (https://git.nostrdev.com/sigit/sigit.io/issues/168, https://git.nostrdev.com/sigit/sigit.io/issues/158). Further testing will be required to confirm before closing each. The commented-out code causes the race condition during the processing of the gift wraps with sigits. During the processing we perform checks to see if sigit is outdated. In cases where sigit includes multiple signers it's possible for a signer to receive multiple sigit updates at once (especially noticeable for 3rd, 4th signer). Due to async nature of processing we can have same sigit enter processing flow with different states. Since this code also updates user's app state, which includes uploads to the blossom server it takes time to upload local user state which causes both to check against the stale data and un-updated app state. This results in both sigits being "new" and both proceed to update user state and upload app data. We have no guarantees as in which event will update last, meaning that the final state we end up with could be already stale. The issue is also complicated due to the fact that we mark the gift wraps as processed and it's impossible to update the state without creating a new gift wrap with correct state and processing it last to overwrite stale state. This is temporary solution to stop broken sigit states until proper async implementation is ready.
enes added 3 commits 2024-09-10 11:12:52 +00:00
chore(git): cleanup
All checks were successful
Open PR on Staging / audit_and_check (pull_request) Successful in 33s
Details
7163f4aae1
enes changed title from fix: race condition during async processing of gift wraps to fix: processing gift wraps and notifications 2024-09-10 11:13:49 +00:00
enes requested review from s 2024-09-10 11:15:27 +00:00
b added 1 commit 2024-09-10 12:44:08 +00:00
Merge branch 'staging' into notification-debug
All checks were successful
Open PR on Staging / audit_and_check (pull_request) Successful in 33s
Details
4c45a227f0
eugene commented 2024-09-11 09:31:59 +00:00
Owner
Copy Link

The next building block would be to ensure that subscriptions stay open while the user is using the app, but for now this should fix a high-priority issue, so it looks good.

The next building block would be to ensure that subscriptions stay open while the user is using the app, but for now this should fix a high-priority issue, so it looks good.
eugene approved these changes 2024-09-11 09:32:16 +00:00
enes added 1 commit 2024-09-11 11:13:23 +00:00
fix: add 2m interval to sigits update
All checks were successful
Open PR on Staging / audit_and_check (pull_request) Successful in 33s
Details
522bdf54de 
hotfix until #194
enes merged commit 235e76be4e into staging 2024-09-12 08:27:00 +00:00
enes deleted branch notification-debug 2024-09-12 08:27:00 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
s
eugene
Labels
Clear labels
Kind/Breaking
Breaking change that won't be backward compatible
Kind/Bug
Something is not working
Kind/Documentation
Documentation changes
Kind/Enhancement
Improve existing functionality
Kind/Feature
New functionality
Kind/Security
This is security issue
Kind/Testing
Issue or pull request related to testing
Priority
Critical
The priority is critical
Priority
High
The priority is high
Priority
Low
The priority is low
Priority
Medium
The priority is medium
Reviewed
Confirmed
Issue has been confirmed
Reviewed
Duplicate
This issue or pull request already exists
Reviewed
Invalid
Invalid issue
Reviewed
Won't Fix
This issue won't be fixed
Status
Abandoned
Somebody has started to work on this but abandoned work
Status
Blocked
Something is blocking this issue or pull request
Status
Need More Info
Feedback is required to reproduce issue or to continue work
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sigit/sigit.io#193
No description provided.
Delete Branch "notification-debug"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?