Page MenuHomePhabricator

[keyserver] Don't block innerPerformAuth return on sleep
ClosedPublic

Authored by ashoat on Mar 31 2024, 7:45 PM.
Tags
None
Referenced Files
F2024838: D11501.diff
Mon, Jun 17, 6:40 AM
Unknown Object (File)
Thu, Jun 13, 5:59 AM
Unknown Object (File)
Wed, Jun 12, 6:28 PM
Unknown Object (File)
Tue, Jun 11, 7:57 PM
Unknown Object (File)
May 7 2024, 4:32 PM
Unknown Object (File)
Apr 26 2024, 6:29 PM
Unknown Object (File)
Apr 12 2024, 5:49 AM
Unknown Object (File)
Apr 7 2024, 2:06 PM
Subscribers
None

Details

Summary

In an earlier version of this stack, in innerPerformRecovery I would fall back on legacy login, and without this change the fallback would have to wait on this sleep.

This didn't used to matter before because nothing actually waits for innerPerformAuth to complete. And since I eventually came to the conclusion that the fallback was a bad idea (we'd be sending user passwords to keyservers), it actually still doesn't matter.

I decided to put this diff up anyways because I think it's probably better for us to avoid blocking the return of innerPerformAuth on this sleep.

Depends on D11500

Test Plan

Confirm in the earlier version of the stack that when falling back on legacy login, there was no delay due to this sleep

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

tomek added inline comments.
lib/components/keyserver-connection-handler.js
182–185

It seems surprising to me that this sleep was blocking the return from innerPerformAuth - this code is part of a promise created on line 114, so it should immediately return. Maybe the reason is to avoid waiting for sleep to complete when awaiting the result of calling innerPerformAuth?

This revision is now accepted and ready to land.Apr 2 2024, 2:47 AM
lib/components/keyserver-connection-handler.js
182–185

Yes, it's about a callsite where we await the result of calling innerPerformAuth. I've highlighted it below

270–275

The issue is that this promise will not resolve until the sleep concludes