rebase

rebase

review feedback

Remove isDefault to pass flow check

remove web migration

match style

consts can be moved to specific unit tests

rename ClientDBIntegrityThreadHashesOperation to ClientDBIntegrityStoreOperation for consistency

add remove to process store ops

rebase

rebase

rebase

review feedback

review feedback

refactor for sync state action

convert thead hash type to text

review feedback. convert thread_hash to string

In D11305#326479, @varun wrote:

1. it's safer. assuming that devs remember to revert to master after testing local changes, we can make sure that things work on staging for a short period before we apply changes to prod. there's no good way to test landed changes for an extended period in the current process without running the risk of a) another dev undoing the changes while testing something on a custom tag or b) the changes being applied prematurely to prod
2. we can see the delta between staging and prod clearly. before, it was possible for staging to be a few releases ahead of prod without any visibility. this is a good (albeit not perfect) forcing function to make sure we keep prod up to date with staging

lmk what you think. curious for @bartek and @will 's thoughts too

rebase

The reduceIntegrityStore function starts with:

if (
  action.type === logInActionTypes.success ||
  action.type === siweAuthActionTypes.success ||
  action.type === keyserverRegisterActionTypes.success ||
  action.type === fullStateSyncActionType ||
  (action.type === setClientDBStoreActionType &&
    !!action.payload.threadStore &&
    state.threadHashingStatus !== 'completed')
) {
  return { threadHashes: {}, threadHashingStatus: 'starting' };
} else if (action.type === keyserverAuthActionTypes.success) {
  return { ...state, threadHashingStatus: 'starting' };
}

build db wasm

add _store to create_integrity_table method

Update hash to number from text and review feedback

review feedback and add remove operation

Looks good to me. We're removing the cache to support stateless sessions correct?

Looks good to me. Might want to adjust the diff title and test plan but that's really it.

In D11200#323719, @varun wrote:

what is IdentitySearchAccessToken? do you mean IdentitySearchAuthMessage?

In D11200#323690, @varun wrote:

can we improve the test plan a little? we should check that if the user isn't logged in we don't get an error

authMetadata to auth message in console log

Downstream the client will no longer attempt to initialize a websocket connection in the identity-search-context. The identitySearchSocketConnected variable in useSearchUsers will remain false and so the function will fallback to keyserver search.