Page MenuHomePhabricator

[lib] correctly skip using established socket when urlPrefix is overriden
ClosedPublic

Authored by ginsu on Nov 2 2023, 1:05 AM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Oct 28, 12:14 AM
Unknown Object (File)
Oct 5 2024, 6:45 PM
Unknown Object (File)
Oct 4 2024, 12:35 PM
Unknown Object (File)
Sep 28 2024, 3:22 AM
Unknown Object (File)
Sep 28 2024, 3:22 AM
Unknown Object (File)
Sep 28 2024, 3:22 AM
Unknown Object (File)
Sep 28 2024, 3:22 AM
Unknown Object (File)
Sep 28 2024, 3:22 AM
Subscribers

Details

Summary

In D9667, I got some feedback about improving the solution for not using an established socket for calling endpoints whenever we override the urlPrefix. This diff addresses that feedback.

Depends on D9667

Test Plan

Created this dummy params override object:

const dummyOverride = {
  urlPrefixOverride: 'testing',
};

And passed it to endpoint calls that would normally use an established socket and confirmed that when we overrode the url prefix with this dummy params override object we were not entering the condition in callServerEndpoint where we use an established socket

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

ginsu requested review of this revision.Nov 2 2023, 1:31 AM
This revision is now accepted and ready to land.Nov 2 2023, 7:00 AM

After merging + rebasing @inka's changes where she introduced the useGetVersion hook, we now use this hook instead of using useServerCall(getVersion). When the useGetVersion hook calls the callServerEndpoint function it will skip using the established socket by default, making this diff not necessary anymore

lib/utils/call-server-endpoint.js
109 ↗(On Diff #32612)

Should this change still be made?

lib/utils/call-server-endpoint.js
109 ↗(On Diff #32612)

No this is no longer necessary since we don't override the urlPrefix directly now. Instead we override the map of keyserverInfos (which contains the new url prefix) with entries for each keyserver we want to connect to. From there we use that map of overridden keyservers to build our map of requests to each respective keyserver.

How we override the map of keyserverInfos:
https://github.com/CommE2E/comm/blob/master/lib/shared/keyserver-utils.js#L18-L23C7

Building our map of requests:
https://github.com/CommE2E/comm/blob/master/lib/actions/device-actions.js#L90-L95

Not sure if this is super relevant to the original question but here's a helpful comment by @inka explaining how we should be using the useGetVersion hook
https://github.com/CommE2E/comm/blob/master/lib/actions/device-actions.js#L79-L83

lib/utils/call-server-endpoint.js
109 ↗(On Diff #32612)

I get that we're not using it, but shouldn't this be the behavior when urlPrefixOverride is set?

If we use the socket when urlPrefixOverride is set, won't that prevent urlPrefixOverride from working?

Unless I'm missing something, I think we either need to still make this change, or we need to deprecate urlPrefixOverride to prevent somebody from using it in the future, as it appears to me that it's very broken (will be straight up ignored if a socket is connected)

ginsu added inline comments.
lib/utils/call-server-endpoint.js
109 ↗(On Diff #32612)

I've thought about this some more, and I was confusing myself by overthinking this just in the context of this get version call. My bad. The intention of this diff should be that whenever we are overriding urlPrefix we never want to use an established socket since that socket won't respect the overridden urlPrefix. So yes we should still check for this so we don't use an established socket if we ever make a server call in the future with an overridden url prefix.

This revision is now accepted and ready to land.Dec 6 2023, 12:50 PM
This revision is now accepted and ready to land.Dec 6 2023, 3:09 PM
ginsu edited the test plan for this revision. (Show Details)
ginsu requested review of this revision.Dec 6 2023, 4:22 PM

rerequesting review as a sanity check for my earlier confusion

This revision is now accepted and ready to land.Dec 8 2023, 6:50 AM