You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Version 0.8 decouples Connection from AccountRegistry, with clients having to add Connection objects to their registry instance instead. However, before successful authentication Connection::userId() returns an empty value.
To Reproduce
Call AccountRegistry::add() on several (two are enough) Connection objects one after another before any of them is authenticated (Connection::assumeIdentity() counts as authentication too).
Observe that only the first Connection object gets added, with a warning on subsequent object(s) in the logs: "Attempt to add another connection for the same user id; skipping".
Expected behavior
Some (stable) MXID-based identification for Connection should work from the very beginning of Connection existence, so that one could add them to AccountRegistry right away. Ideally, MXID should not even change during Connection lifecycle but that's a separate story, effectively the same as #439.
Is it environment-specific?
libQuotient 0.8 beta
The text was updated successfully, but these errors were encountered:
Describe the bug
Version 0.8 decouples
Connection
fromAccountRegistry
, with clients having to addConnection
objects to their registry instance instead. However, before successful authenticationConnection::userId()
returns an empty value.To Reproduce
AccountRegistry::add()
on several (two are enough)Connection
objects one after another before any of them is authenticated (Connection::assumeIdentity()
counts as authentication too).Connection
object gets added, with a warning on subsequent object(s) in the logs: "Attempt to add another connection for the same user id; skipping".Expected behavior
Some (stable) MXID-based identification for
Connection
should work from the very beginning ofConnection
existence, so that one could add them toAccountRegistry
right away. Ideally, MXID should not even change duringConnection
lifecycle but that's a separate story, effectively the same as #439.Is it environment-specific?
The text was updated successfully, but these errors were encountered: