Setting the default handler and ex_syslogger handler levels does not
necessarily have to set the primary logger log level, at least in the
future. Without this, the primary log level might be lower than the
configured console/syslog levels, which would cause some desired logs to
not be logged.
Trying to do a two-release migration proved to be very hacky and ugly.
Instead this is preparation for moving defaults first and then merging
the old configuration left in admin's config file at runtime while still
emitting a warning. This hopefully will be a lot nicer and less
complicated.
Elixir 1.19 started emitting warnings about our use of:
config :logger, :console and
config :logger, backends: []
which got split in 1.15 to :default_handler, :default_formatter, and
LoggerBackends.add(backend) respectively.
On Pleroma startup it is now necessary to add the additional logger
backends at runtime (done with configure_logger() in application.ex).
New config key :pleroma, :logger_backends: [] has replaced the older
backends array. The logger_backends package is now used to facilitate
usage of other logger backends besides the default one (:logger_std_h
from OTP).
Warnings were added to Pleroma startup to warn about the usage of
:logger, backends and additional logic was introduced to make addition
of ExSyslogger to admin's configuration less dumb.
Ref: https://hexdocs.pm/logger/1.15.0/Logger.html#module-backends-and-backwards-compatibility
Make ParadeDB search typo-tolerant via configurable fuzzy distance and document the new setting. Add coverage for fuzzy query SQL and id parsing, and keep integration test stability under connection load.
Introduce an optional search backend that indexes public/unlisted Notes into a separate ParadeDB (pg_search) Postgres and queries it for status search results.
It will check reachability for an instance deemed unreachable at the following intervals:
4 attempts, once a minute
4 attempts, once every 15 minutes
4 attempts, once every 60 minutes
4 attempts, once every 8 hours
4 attempts, once every 24 hours
This should be effective and respectful of the resources of instances on the fediverse.
We have the Oban Pruner plugin enabled to keep the Oban Jobs table from growing indefinitely. It prunes every 15 minutes, but this will interfere with our ability to enforce uniqueness on the ReachabilityWorker jobs for a time period longer than 15 minutes. The solution is to exclude the ReachabilityWorker from the pruning operation and instead schedule a custom job that will prune the table for us once a day. The ReachabilityPruner cron task will clean up the history of the ReachabilityWorker jobs older than 6 days.
The result of Oban jobs determine the reachability status.
Publisher jobs will cancel themselves at execution time if the target server is now unreachable.
Receiving activities does not immediately mark a server as reachable, but creates a ReachabilityWorker job to validate.
A Cron will execute daily to test all unreachable servers.
