The other invocations use it that way, and the only listener in trunk
which uses it (in mod_presence) expects it that way.
Passing the username of the JID from the removed entry causes incorrect
unavailable presence stanzas to be sent, allegedly kicking people off
MUCs.
Fixes#1121.
There was an off-by-one in the modulo calculation. Switching to a plain
old array-table makes the apparent size of the queue wrong, but since
some of the queue may not be available this is likely for the best.
Meant to be used in mod_smacks for XEP-0198
Meant to have a larger virtual size than actual number of items stored,
on the theory that in most cases, the excess will be acked before needed
for a resumption event.
Ie. log("debug", "%d", "\1\2\3") should not result in garbage.
Also optimizing for the common case of ASCII string passed to %s and
early returns everywhere.
Returning nil from a gsub callback keeps the original substring.
Should prevent invalid UTF-8 from making it into the logs, which can
cause trouble with terminals or log viewers or other tools, such as when
grep determines that log files are binary.
The numeric error codes seems to have been removed from the examples in
XEP-0045 version 1.24, and were deprecated even by RFC 3920 in 2004,
only allowed for backwards compatibility.
Running woken runners in the next iteration of the event loop prevents
unexpected recursion, unexpected tracebacks, and is generally more
predictable.
The pattern is borrowed from util.promise, where we're now doing the same.
No scheduler set by default, so it will error (we plan to initialize it in
util.startup).
We wanted to avoid a hard dependency on util.timer (which in turn depends on
network backends, etc.), and we didn't add timer.sleep() because we didn't
want to add a hard dependency on util.async for things that don't need it.
Could not reproduce locally but it complained in CI that
> spec/util_promise_spec.lua:676: Cannot spy on type 'nil', only on functions or callable elements
Assumes that most number fields are integers, as most numeric types
listed in XEP-0122 are, as are all such fields in Prosody as of this.
Otherwise %g produces something like 1.1259e+15
Clients would generally be using the "max" symbol instead of discovering
this, but this also gets us validation and earlier rejection of out of
bounds values.
Default left as 'never' in mod_pubsub to preserve the previous behavior.
Unclear if this is desirable, but can always be changed later.
In mod_pep this allows turning off the automatic resending of most
recent item.
Storage drivers may issue their own IDs tho none of the included ones do
this atm, but the 3rd party module mod_storage_xmlarchive has its
special format.
XEP-0060 says that this the way to indicate that 'persistent-items' is
unsupported, but doesn't explicitly say if it being disabled in the node
configuration also counts as unsupported.
When set to 'false' there is no need for a persistence interface at all,
since items are not persisted after being broadcast.
Had started wondering if maybe the behavior was wrong, after reading
parts of XEP-0060 that pointed in that direction.
Some discussion of this can be found in logs of
xmpp:xsf@muc.xmpp.org?join from around 2021-07-20
Thanks to Ralph for confirming.
Since nodes were always persistent according to the XEP-0060 definition.
Whether data is stored in memory or on disk was not what this setting
was meant for.
Allows testing e.g. opportunistic writes or other settings easily in CI
or otherwise without editing the config file.
make integration-test PROSODY_NETWORK_SETTINGS='{"opportunistic_writes":true}'
Character sequences could be split across chunk boundaries. Would require a bunch
of code to make that work reliably.
Only apply front_consumed on first chunk, and adjust buffer_pos accordingly.
