fix: apply login credentials to client after Matrix password auth#5829
fix: apply login credentials to client after Matrix password auth#5829teyrebaz33 wants to merge 5 commits into
Conversation
|
Thanks for the PR! I have some additional information that might help confirm the fix: Even when using a manually generated MATRIX_ACCESS_TOKEN, the issue persists. It’s not "silent" in the sense of zero output; rather, the bot seems to be stuck in a loop. Every time I send a new message to the bot (even in a fresh, unencrypted room), the log immediately repeats the exact same decryption warnings from the initial sync: The bot never responds. When I try to use a command like /sethome, the Matrix client (Element) just shows "Unknown command", indicating that the event is sent to the server, but the Hermes gateway isn't successfully "consuming" and processing it due to the loop. The bot clearly "sees" that there is a new event on the server (hence the triggered log output), but it seems to "forget" its sync position or credentials, forcing it to re-play the old encrypted timeline instead of moving forward. |
|
Thanks for the additional context @Schnurzel700. The symptom you describe with access-token auth (decryption warnings replaying on each new message) points to a separate issue from what this PR fixes — when credentials are already applied correctly via This PR specifically fixes the password-login path where |
Comprehensive walkthrough covering: - Three methods for finding bugs (usage, code reading, open issues) - Verifying a real bug before writing code - Tracing root causes through the full code path - Opening well-structured issues - Writing minimal, pattern-following fixes - Writing regression tests - Pre-PR checklist with exact commands - Opening PRs with clear descriptions - Handling CI failures and the salvage pattern All examples drawn from real merged PRs (NousResearch#5080, NousResearch#5829).
3f67f76 to
fe8e312
Compare
…usResearch#5819) When using MATRIX_PASSWORD, the LoginResponse from matrix-nio was being discarded after a successful login. The client was left without an access_token, user_id, and device_id, so all subsequent sync() calls were effectively unauthenticated — silently delivering no new events. Apply all three credentials from the LoginResponse to the AsyncClient immediately after login, mirroring what the access-token path already does via restore_login(). Also update self._user_id so session tracking and deduplication use the server-canonical user ID. Adds a regression test that asserts all three fields are propagated from LoginResponse to the client after a successful password login.
…on restart Without updating self._device_id from the LoginResponse, each gateway restart passes None as ctor_device_id to AsyncClient, causing matrix-nio to create a new device identity on every login and flooding the account with stale sessions. Reported in NousResearch#5819 follow-up by Schnurzel700.
…dd clock-skew tolerance Two fixes for the silent Matrix gateway issue reported in NousResearch#5819: 1. receive_response() was missing from _sync_loop. matrix-nio's sync() only fetches data over HTTP — receive_response() is required to actually dispatch events to registered callbacks. Without this call, the bot syncs data but never fires _on_room_message or any other registered handler. 2. The startup grace period compared server-side UTC timestamps against local system time without clock-skew tolerance. Added a 60-second tolerance to prevent new messages from being incorrectly discarded as stale when local and server clocks drift. Root cause identified and verified by Schnurzel700 in NousResearch#5819.
The initial sync call also requires receive_response() to trigger registered callbacks, not just the sync loop. Without this, the bot deadlocks/remains silent at startup even with the sync loop fix. Identified from working implementation shared by Schnurzel700.
…ag and add dispatch diagnostic - Replace clock-skew-prone timestamp grace period with _initial_sync_done flag - Add debug log before handle_message dispatch to diagnose silent failures - Approach based on working implementation from Schnurzel700 (NousResearch#5819)
fe8e312 to
5c6855a
Compare
|
Superseded by #7881 |
Problem
Fixes #5819.
When using
MATRIX_PASSWORDauthentication, the bot connects and processes the initial sync, but silently ignores all subsequent messages with zero log output.Root Cause
After a successful
client.login(), theLoginResponsewas being discarded. matrix-nio does not automatically apply the response to the client —access_token,device_id, anduser_idmust be set manually. Without these, subsequentsync()calls are effectively unauthenticated and deliver no new events.The access-token path already handles this correctly via
restore_login(). The password path was missing equivalent credential application.Fix
Apply all three credentials from
LoginResponseto theAsyncClientimmediately after a successful password login:Tests
Added
TestMatrixPasswordAuth.test_connect_applies_credentials_from_login_responsewhich verifies that all three fields fromLoginResponseare propagated to the client after a successful password login.