Repository navigation
Merged
Conversation
sv_ev_connection_features_received() waited for all items returned by disco#items to finish before firing. Which meant that session features like OMEMO, carbons, bookmarks, MAM were blocked on external components like MUC or HTTP upload. External components can take a long time. On servers with slow or unreachable components, this delayed the session. And because the bare JID disco#info was not tracked, it created a race where OMEMO attempted to publish its bundle before PEP features were received, failing with "no PUBSUB feature announced". On servers with no disco items at all, discovery completion was never triggered. Core session features only depend on the server domain and the user's bare JID. Now track domain and bare JID queries in account_features_requested and trigger sv_ev_connection_features_received() as soon as both resolve. Also modernize iq_disco_items_request_onconnect() to use an ID handler instead of matching on hardcoded string IDs. Ref: #2078 Signed-off-by: Michael Vetter <jubalh@iodoru.org>
When MAM history retrieval fails we printed: "Server error: <condition>" message to the console without context. Include the target JID and clarify that the error originated from MAM so users can identify which chat/MUC failed. Signed-off-by: Michael Vetter <jubalh@iodoru.org>
Include the target JID when available so the user knows which chat failed. Signed-off-by: Michael Vetter <jubalh@iodoru.org>
MAM can be enabled per MUC and not just server wide. Include the target JID and distinguish between regular chats and MUC so the user knows which chat could not fetch history. Signed-off-by: Michael Vetter <jubalh@iodoru.org>
Rename received_disco_items to feature_retrieval_completed to accurately reflect its purpose. Also ensure it is also reset to FALSE in iq_handlers_clear() so that history requests are properly queued during reconnections. Signed-off-by: Michael Vetter <jubalh@iodoru.org>
1 task
MAM support for MUCs is advertised by the MUC room itself via service discovery, independent of the users home server. See XEP-0313. We checked in iq_mam_request_older(), _iq_mam_request(), and `/history verify` the result of connection_supports(XMPP_FEATURE_MAM2). Because room JIDs are not tracked in conn.features_by_jid, this caused: * False negatives: history was rejected with "MUC <room> does not support MAM" if the users home server lacked MAM, even when the MUC room fully advertised it. * False positives: invalid MAM queries were sent to MUC rooms that did not support MAM if the users home server advertised MAM. We need to use muc_supports_mam() for MUC windows and connection_supports() for 1:1. Also remove the window loading indicator if iq_mam_request_older() aborts early due to lack of support. Signed-off-by: Michael Vetter <jubalh@iodoru.org>
When a disco#info response on connect failed to find the target in features_by_jid, _disco_info_response_id_handler_onconnect() returned 1. In _iq_handler(), returning a non zero value signals that the handler should be kept in id_handlers. Because a response for this stanza ID has already arrived and the ID will never be reused, this leaked the handler in memory indefinitely. Returning early without calling connection_features_received() prevented account_features_requested from decrementing if the failed JID was tracked, causing account discovery to hang forever. Signed-off-by: Michael Vetter <jubalh@iodoru.org>
Decoupling account readiness from component discovery meant that user commands could be executed while background disco for external components (HTTP upload, MUC) was still going on. If a user executed `/sendfile` or `/join room` without a domain immediately after connect, connection_jid_for_feature() returned NULL resulting in: * "XEP-0363 HTTP File Upload is not supported by the server" * "Account MUC service property not found." So let's track component discovery via components_requested and discovering_components. When a command executes while component discovery is still active, let the user know that discovery is in progress rather than claiming lack of server support. Signed-off-by: Michael Vetter <jubalh@iodoru.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
For users that got
no PUBSUB feature announcedandServer error: item-not-foundthis should improve the situation.Decouple Account Readiness from Component Discovery:
finish discovery
iq_disco_items_request_onconnect()to use generated stanza IDs and dedicated ID handlers.Resolve Discovery Lookup Leaks Hangs:
_disco_info_response_id_handler_onconnect()returning 1 when the features lookup is NULL, which previously leaked the handler inid_handlersand stalled account discovery indefinitely.Align MUC MAM with XEP-0313 :
Guard Against Component Discovery Races:
/sendfileor/joincommands executed before background disco completes.