Change Details

The logic in the keyserver's `fetchDataForSocketInit` method is written to handle session setting in a peculiar way. The normal session setting mechanisms rely on the result being processed by `callSingleKeyserverEndpoint`. When a session is set during a socket initialization, the new session is written into the result, and the caller is expected to extract it and handle it manually. Since `fetch_pending_updates` is called from `callSingleKeyserverEndpoint` on the client, we could consider an alternative here, where `fetchDataForSocketInit` would only behave this way when called from an actual socket (as opposed to `fetch_pending_updates`). I decided it would be more simple to leave the keyserver code as-is, and to handle the received session on the client side. Open to the alternative if it's preferred. Depends on D12387

The logic in the keyserver's `fetchDataForSocketInit` method is written to handle session setting in a [peculiar way](https://github.com/CommE2E/comm/blob/a936d5f5ebacbf3a84ced3708a8e2fbc5da7f155/keyserver/src/socket/fetch-data.js#L94-L102). The normal session setting mechanisms rely on the result being processed by `callSingleKeyserverEndpoint`. When a session is set during a socket initialization, the new session is written into the result, and the caller is expected to extract it and handle it manually. Since `fetch_pending_updates` is called from `callSingleKeyserverEndpoint` on the client, we could consider an alternative here, where `fetchDataForSocketInit` would only behave this way when called from an actual socket (as opposed to `fetch_pending_updates`). I decided it would be more simple to leave the keyserver code as-is, and to handle the received session on the client side. Open to the alternative if it's preferred. Depends on D12387

The logic in the keyserver's `fetchDataForSocketInit` method is written to handle session setting in a peculiar way[peculiar way](https://github.com/CommE2E/comm/blob/a936d5f5ebacbf3a84ced3708a8e2fbc5da7f155/keyserver/src/socket/fetch-data.js#L94-L102). The normal session setting mechanisms rely on the result being processed by `callSingleKeyserverEndpoint`. When a session is set during a socket initialization, the new session is written into the result, and the caller is expected to extract it and handle it manually. Since `fetch_pending_updates` is called from `callSingleKeyserverEndpoint` on the client, we could consider an alternative here, where `fetchDataForSocketInit` would only behave this way when called from an actual socket (as opposed to `fetch_pending_updates`). I decided it would be more simple to leave the keyserver code as-is, and to handle the received session on the client side. Open to the alternative if it's preferred. Depends on D12387