`session:dispatch_stanza(pres)` enqueues processing of the stanza in the
sessions async thread, but becasue the entire stream close handling is
now in that thread it would process the presence after the stream and
session was completely closed, leading to weird errors "sent to a
resting session".
We call core_process_stanza() since this is what :dispatch_stanza calls
in the end.
27f5db07bec9 fixed this wrong. The code is supposed to check if the
stanza is NOT sent to your bare JID. A MUC PM is always sent to your
full JID. Hopefully nobody sends MUC invites to full JIDs, because those
would be skipped by this as well.
A large share of `<presence type=error>` appears to be noise from large
public channels and failed presence probes. The later at least should
count as presence updates, which are currently considered unimportant.
See also 8cecb85e4bc4 which is partly reverted here. The intent there
was probably mostly about message (delivery) errors, which should be
considered important.
With mod\_storage\_internal this counts out to 100 messages out of 10 000,
meaning should not hit the quota limit immediately until that many
messages have been added again.
Passing around PIDs, UIDs etc as integers makes it more sane in Lua 5.3.
Getting 1234.0 as PID is silly. Shouldn't change any behavior as these
are all integers on the C side and the integral floats are accepted as
integers when passed back from Lua into C.
Typing e.g. `c2s` would dump out a bunch of stuff that would probably
just confuse users.
Now you only get pretty-printing when poking around in the internals
with `>`.
If nickname enforcement is enabled this would otherwise let you bypass
the join check in muc.lib by registering an invalid nickname and then
joining with any nickname, letting register.lib change it to the invalid
registered nick.
This is meant to help trace down an issue where Prosody apparently
creates multiple conflicting SQL engines, causing problems especially
with SQLite3, e.g. #616#784.
This makes it much nicer to inspect Prosody internals.
Existing textual status messages from commands are not serialized to
preserve existing behavior. Explicit serialization of configuration is
kept in order to make it clear that returned strings are serialized
strings that would look like what's actually in the config file.
The default maxdepth of 2 seems ought to be an okay default, balanced
between showing enough structure to continue exploring and DoS-ing your
terminal.
Thanks to Ge0rG for the motivation to finally do this.