| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
The more tests I made, the more Lua 5.1 quirks I discovered.
Tests generated using a tool plus some touch-up.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
This should rule out error replies to PEP notifications, which come from
the account bare JID, and would be reflected back to it if they can't be
delivered for some reason, e.g. s2s problems.
|
|
|
|
|
| |
Including the payload of the stanza that caused the error is optional
and we're generally not doing it anywhere else.
|
|
|
|
|
| |
Mistake introduced in cbe524ed1a6a. Removing because this is a query to
the bare JID where the error origin matches the resulting stanza 'from'.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
I spend several minutes confused over where the bug was until I
remembered I had set myself as visitor in the previous debug session.
This would have helped.
|
|
|
|
|
| |
Not a particularly user-friendly error message, but better than "unable
to resolve service" and having no clue where it came from.
|
|
|
|
|
| |
This should allow modules to override the username in a profile handler by
assigning to self.username.
|
|
|
|
|
| |
Allows inferring whether Direct TLS was used, or perhaps which SRV
record was chosen. Not shown by default.
|
|
|
|
|
| |
It was previously set to the hostname, not the users bare JID which
would be correct.
|
|
|
|
|
| |
This allows overriding it in cases where it is not equal to module.host,
like say, in mod_pep
|
|
|
|
| |
So that the methods are there and don't cause an error.
|
|
|
|
| |
Is it not odd that um.set_roles() takes `nil` to mean global?
|
| |
|
|
|
|
|
| |
If you already know the account, from say the server contact info, then
this confirms their admin status.
|
|
|
|
| |
Can these even be seen?
|
| |
|
|
|
|
|
|
|
|
| |
Needed to e.g. grant admin rights on a component, or grant non-local
users local privileges.
Leave the same host syntax for convenience, since this might be the
common case.
|
|
|
|
|
| |
This would allow e.g. granting admin status without changing the config
and without a restart.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
With opportunistic writes enabled, writes can return what :onwritable()
returns, thus :onwritable() should return something sensible at each
spot.
Should prevent whatever caused
> Error writing to connection: (nil)
Tho this was probably harmless
|
| |
|
|
|
|
|
| |
This makes it easier to reschedule or otherwise manipulate the timer
from e.g. the shell, which is handy for debugging.
|
|
|
|
| |
It was lost in 6f4790b8deec when switching to mod_cron.
|
|
|
|
|
| |
Prefer 'prune' over 'delete' since it more strongly implies removal of
excess.
|
| |
|
|
|
|
|
| |
Before aa60f4353001 each loop had its own counter, seems incrementing of
one of them was lost. But only one is needed anyhow.
|
| |
|
|
|
|
|
|
| |
Before mod_cron this job ran less frequently than the upload removal
job. Running them at the same frequency seems wasteful somehow, plus the
total should not drift away from the true value that fast.
|
| |
|
|
|
|
|
| |
Makes it more generic so new periods (e.g. weekly etc) can be added
easily.
|
| |
|
|
|
|
|
| |
The value needs to be known in order to determine if additional uploads
can be accepted.
|
|
|
|
| |
Passing nil to the metrics system causes errors later.
|
|
|
|
|
| |
Since reply.attr.to will be the .attr.from of the input we can check
this earlier and avoid constructing the reply at all.
|
|
|
|
| |
Did error_reply() not exist when mod_smacks was first created?
|
|
|
|
|
|
| |
Eventually the goal is to have daily tasks run while there is little
activity, but that will vary with the server and the usage patterns of
its users. This is a start anyway.
|
|
|
|
|
| |
Merging those loops removes the miscounting that would occur in case a
file could not be deleted, so no need to limit it to that case.
|
|
|
|
|
|
|
|
| |
Not sure what the benefit of two separate loops was, perhaps reduced
memory usage by allowing archive query state to be garbage collected
before moving on to deleting files. Never measured so probably not so.
This simplifies a bit.
|
|
|
|
|
|
| |
This is probably a bad idea, as files that could not be deleted for some
reason will not be tried again. I was just thinking of what the 'task'
argument could be used for.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
A number of modules now have periodic tasks that need to run, e.g. for
cleaning out old messages or files. This has highlighted a need for
coordinating and optimizing scheduling of such tasks.
|