Page MenuHomePhabricator

[lib] Don't automatically log out on connection issue when using CSAT
ClosedPublic

Authored by tomek on Jan 26 2024, 8:48 AM.
Tags
None
Referenced Files
F3522844: D10842.diff
Mon, Dec 23, 7:43 AM
F3521493: D10842.id36624.diff
Mon, Dec 23, 3:41 AM
F3521492: D10842.id36185.diff
Mon, Dec 23, 3:41 AM
F3521479: D10842.id.diff
Mon, Dec 23, 3:41 AM
F3521470: D10842.diff
Mon, Dec 23, 3:41 AM
Unknown Object (File)
Wed, Dec 11, 7:45 PM
Unknown Object (File)
Tue, Dec 3, 10:03 AM
Unknown Object (File)
Nov 6 2024, 1:24 PM
Subscribers

Details

Summary

Instead the handler should retry a connection.

Depends on D10834

Test Plan

Set a flag, dispatch connection issue and check if a user won't get logged out.

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

tomek requested review of this revision.Jan 26 2024, 9:09 AM

Is this what we want to do for all connection issues, even for my keyserver? Or are there some kinds of connection issues, where if they occur for my keyserver, we'd want to log the user out?

Is this what we want to do for all connection issues, even for my keyserver? Or are there some kinds of connection issues, where if they occur for my keyserver, we'd want to log the user out?

We probably should prefer treating all the keyservers the same. As for the connection issues, I'm wondering if e.g. not_logged_in_error is something from which we can recover - it is set after our socket receives not_logged_in message.

I think yes, we can recover from that. To be honest, it's a weird one... it can only happen if a client attempts to connect with a keyserver socket using an anonymous cookie, but based on the client code that should not be possible. But if it does somehow happen, the solution is just for the client to attempt the login.

tomek requested review of this revision.Jan 31 2024, 7:52 AM

For now I think this makes sense, and I don't want to hold up the stack

This revision is now accepted and ready to land.Feb 3 2024, 9:41 AM