Page MenuHomePhabricator

[lib] Add action type to remove peer user
ClosedPublic

Authored by bartek on Aug 4 2024, 11:45 PM.
Tags
None
Referenced Files
F3331801: D12962.id43098.diff
Wed, Nov 20, 9:41 PM
F3331800: D12962.id43097.diff
Wed, Nov 20, 9:41 PM
F3331799: D12962.id43107.diff
Wed, Nov 20, 9:41 PM
Unknown Object (File)
Sat, Nov 9, 4:39 PM
Unknown Object (File)
Fri, Nov 8, 2:15 PM
Unknown Object (File)
Fri, Nov 8, 12:31 PM
Unknown Object (File)
Fri, Nov 8, 12:29 PM
Unknown Object (File)
Fri, Nov 8, 11:52 AM
Subscribers

Details

Summary

Similiar to D12961, but for relyingOnAuthoritativeKeyserve = false.
Added new action type that removes user IDs from both userStore and auxUserStore.
The action is dispatched when a peer receives message about account deletion.

Depends on D12961

Test Plan

The same as D12961, but this time faked relyingOnAuthoritativeKeyserver = false by reversing conditions for this flag in reducers.

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

bartek held this revision as a draft.
bartek published this revision for review.Aug 5 2024, 2:27 AM

I think we can remove relyingOnAuthoritativeKeyserver from the condition, even if we still have an authoritative keyserver why not proceed with processing P2P messages as we should, in the worst case we attempt to delete the same peer twice, but wondering what @inka is thinking.

lib/reducers/user-reducer.js
548–559 ↗(On Diff #43060)

I would inline those two as we don't call findStoreInconsistencies here

This revision is now accepted and ready to land.Aug 5 2024, 4:56 AM
inka requested changes to this revision.Aug 5 2024, 5:17 AM

I think we can remove relyingOnAuthoritativeKeyserver from the condition, even if we still have an authoritative keyserver why not proceed with processing P2P messages as we should, in the worst case we attempt to delete the same peer twice, but wondering what @inka is thinking.

I agree. Make sure to remove both places the condition is used

lib/reducers/aux-user-reducer.js
203 ↗(On Diff #43060)

Shouldn't we be returning removeUsersOps?

This revision now requires changes to proceed.Aug 5 2024, 5:17 AM

Return missing ops, remove conditions

Inline unnecessary variable

This revision is now accepted and ready to land.Aug 5 2024, 5:34 AM
This revision was landed with ongoing or failed builds.Aug 5 2024, 5:54 AM
This revision was automatically updated to reflect the committed changes.
lib/reducers/aux-user-reducer.js
190

Confused why we don't check relyingOnAuthoritativeKeyserver here, but we do check for it in user-reducer.js below

lib/reducers/user-reducer.js
539

@inka said this in their review:

I agree. Make sure to remove both places the condition is used

Was this place missed?

In the initial revision (https://phab.comm.dev/D12962?id=43060) there were 3 places with relyingOnAuthoritativeKeyserver check:

  1. before action dispatch
  2. in AuxUserReducer
  3. in UserReducer

Perhaps I misunderstood the feedback.
I was under impression that it should be removed from AuxUserReducer (my thinking when reading @kamil's feedback: "removing peer twice" -> peer list is stored in aux user store) so I removed "both conditions" (@inka's feedback) 1. and 2, leaving UserStore up to authoritative keyserver.

I created D13041, where we can continue this discussion