In order to get the signedIdentityKeysBlob, we're going to need to await commCoreModule.getUserPublicKey. As a first step, we refactor getClientResponsesSelector so we'll be able to await getUserPublicKey inside.
Details
Details
Set breakpoints and ensure that native/web send responses as expected and keyserver continues to get responses as expected. Will also be tested implicitly by subsequent diffs.
Haven't done this yet, will test before landing.
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Branch
- arcpatch-D7034 (branched from master)
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
| lib/selectors/socket-selectors.js | ||
|---|---|---|
| 167 ↗ | (On Diff #23616) | The change to getSignedIdentityKeysBlob doesn't appear to be in this diff. This is "okay" since await doesn't do anything if passed a non-promise IIRC, but I still don't think we should be awaiting here if getSignedIdentityKeysBlob doesn't return a Promise |
| lib/socket/request-response-handler.react.js | ||
| 74 ↗ | (On Diff #23616) | Maybe we should just pass serverRequests in here tbh |
| lib/selectors/socket-selectors.js | ||
|---|---|---|
| 167 ↗ | (On Diff #23616) | getSignedIdentityKeysBlob(...) actually remains completely unimplemented as of this diff. However, the "contract" or interface or whatever of getSignedIdentityKeysBlob() does change in this diff to return a Promise so I think having this await is fine? |
| lib/socket/request-response-handler.react.js | ||
| 74 ↗ | (On Diff #23616) | I'm open to either way. Going to land as-is, but will create a Linear task and handle in followup: https://linear.app/comm/issue/ENG-3300/consider-handling-getclientresponses-within |
Comment Actions
Haven't done this yet, will test before landing.
Set breakpoint in processClientResponses(...) and ensured that clientResponses were as expected:
