Closed
Conversation
Codecov Report
@@ Coverage Diff @@
## master #511 +/- ##
===========================================
- Coverage 100.00% 99.24% -0.76%
===========================================
Files 112 113 +1
Lines 14416 14527 +111
Branches 2725 2743 +18
===========================================
+ Hits 14416 14418 +2
- Misses 0 105 +105
- Partials 0 4 +4
Continue to review full report at Codecov.
|
951ee6b to
64457cd
Compare
Collaborator
|
Dear Chris,
There have been many updates since slixmpp 1.7.1 was released in April 2021, see [1]. Specifically, according to what you reported about above, I am looking at [2] here. I would recommend checking Apprise with the current development head of slixmpp, and, if that proves to be successful, to kindly ask the upstream authors for a new release on PyPI. With kind regards, [1] https://lab.louiz.org/poezio/slixmpp/-/commits/master |
|
It's not working. And I found why. It eats the first letter off the recipient address. |
|
When tried with "_" before the recipient login, still get the error, but the message comes through! |
|
The error at the end is only a log of not anything important (and I hope to have it removed by the next release, which should be around the corner), but I have reviewed the code and I do not see where inside that PR or slixmpp the first letter could be mangled. |
Owner
Author
This is actually a bit of a problem because under-the-hood, silxmpp closes the event loop which affects any parent systems using it. One of the things needed to this branch to go forward would be to generate a thread (so it has it's own event loop) and run the notification there. I'll see if i can investigate the other issue you found with the first letter of the recipient being removed. |
In this case it should be much easier, just don’t use |
64457cd to
be89d5c
Compare
Owner
Author
|
@drequivalent ; i believe i fixed the recipient parsing issue. @mathieui, were you able to handle the closing of the event loop? I'd prefer to fix Apprise to use that version and higher. Also @mathieui, there appears to be an issue with the internal DNS of xmpp where it will hang indefinitely if the Edit: @drequivalent - would you by chance be able to test the latest branch here? |
aea6d29 to
9b9942a
Compare
Owner
Author
|
Updated test coverage; but in doing so, i uncovered a situation where slixxmpp still isn't correctly reporting correctly. When an instance of the slixxmpp library has already spun up and connected, multiple instances spun up thereafter, do not seem to work (hence the second instance reports it's connected when it hasn't at all yet; it's almost as though it's using some central reference (or reading from the previous initialization in memory). Will still need to investigate running just this plugin in it's own thread if it were to continue to be supported. The only other catch is if the server can't be connected to, there doesn't appear to be a timeout option (maybe there is, i haven't gone through the slixxmpp source code yet) to eventually stop connecting. Just specifying an invalid host would be a DOS. |
4 tasks
Collaborator
|
Hi again, might https://lab.louiz.org/poezio/slixmpp/-/merge_requests/164 by @linkmauve be of any interest in this context? With kind regards, |
Closed
This was referenced Feb 20, 2026
This was referenced Feb 20, 2026
Closed
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
6 participants
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.
Description:
Related issue (if applicable): #497
Re-factored the way the connections are handled.
Deadlocks and Crashes:
I spent hours trying different things and haven't gotten to far. I may have fixed just the connection issue you were receiving earlier though @drequivalent.
The Issues:
slixmppis that that there seems to be incompatibilities with Python >=3.8. This made it tough to troubleshoot timeouts and forever values for me. Theasyncio.loopseems to deadlock from time to time under certain conditions.jidcan't be resolved (something like?jid=user@405c5318a47031) The built in DNS feature seems to block indefinitely if it fails to resolve. This may also just be related to my Python version incompatibilities. I can't seem to find an easy way to just completely disable DNS. Most exploits always come down to DNS anyhow (such as the recent Apachelog4j2issue in the news). Ideally this should be turned off.@linkmauve do you have any suggestions? Perhaps you could review my PR and let me know if you spot anything unusual?
Side Notes
I know very little about XMPP; this is one of those features i was hoping to just adopt through a 3rd party library. The concerns i have with the deadlocks is that they introduce a denial of service attack for people hosting this via the Apprise API. I may need to disable XMPP there by default for the time being.
Going forward:
There is the thought of maybe switching to a different library; possibly:
silxmppand clean up the issues we're having. I see leveraging the creation of a secondasyncio.loopand putting all of the calls to this library in it's own thread. This will allow it to avoid deadlocking in the main loop and it will also allow me to put a async timeout on the entire call to it when/if the deadlocks continue. Will definitely want your thoughts feedback here @linkmauve (if you have time)Any advice would be welcome 🙏
Testing
Anyone can help test this source code as follows:
Additional
Checklist
flake8)