Closes#5052
Multi-line input is currently sent as one PRIVMSG per line, so a paste
arrives as N unrelated messages. On networks that support
[draft/multiline](https://ircv3.net/specs/extensions/multiline) it can
be sent as a single BATCH and stays one message everywhere.
## Summary
Sending goes through `sayMultiline()` in `plugins/inputs/msg.ts` when
the network advertises limits we can respect (`multilineLimits()`); if
the batch is over max-bytes/max-lines the send falls back to individual
messages, and the local echo follows whichever path was actually taken
so the sender sees what everyone else got. `Client.input()` stops
splitting on newlines when the target network has the cap. Inbound
batches arrive from irc-framework already reassembled and are flagged
`multiline` on the `Msg`, which drives line-by-line rendering (`parse()`
joins lines with `<br>`), one entry per message in the text logs, and a
first-non-empty-line notification preview. `MULTILINE_*` standard
replies get readable text.
No pin bump: `master` already points at the irc-framework commit that
carries multiline (kiwiirc/irc-framework#414).
## Test Plan
- New unit tests for the send path (batch, fallback on max-bytes, no
limits advertised, blank lines), the text log format, `parse()`, and the
standard replies.
- Ran the server against a local IRCd advertising `draft/multiline` and
confirmed on the wire: a 3-line message goes out as one `BATCH …
draft/multiline` with three frames; with the cap advertised bare (no
limits) or with `max-bytes` too small it degrades to three plain
PRIVMSGs and the local echo degrades with it; a CRLF paste sends clean
frames and echoes without stray `\r`; an inbound batch from another user
renders as one message.
- Not verified: rendering was checked through unit tests rather than in
a browser.
Fixes#5103
Today, `getMessages()` filters by `(network, channel)` but sorts by
`time DESC, id DESC` and no index covers both (and a new one supersedes
`network_channel`). This has always been an issue but
https://github.com/thelounge/thelounge/pull/5055 made this code
synchronous which exposed it.
| | Before | After |
|--------|--------|--------|
| history load, 5 channels (4.4M rows total, busiest 3M) | 6.9s, event
loop blocked | 80ms |
| single channel with 3M messages | 4.6s | 18ms |
| query plan | index scan + temp B-tree sort | index only |
it complains that the call `ldap.parseDN(dn).toString();` yields
"[object Object]" but that's bogus... the typing is incorrect.
ldap.DN stringifies properly
This is laying the foundation to build a cleaning task that's
sort of database agnostic.
All calls are done by acting on a "DeletionRequest" so interpretation
of the config will go through a single point
We keep repeating ourselves, let's move that into a helper instead.
In order to get a sane host, we fix the listener to 127.0.0.1
else we get the unspecified :: ipv6 addr (on suitable hosts),
which isn't useful.
We keep repeating ourselves, let's move that into a helper instead.
In order to get a sane host, we fix the listener to 127.0.0.1
else we get the unspecified :: ipv6 addr (on suitable hosts),
which isn't useful.
This enables db migrations to be undone, or "down migrated".
The down migration shouldn't be done automatically
as it could lead to severe data loss if that were done.
Hence, we still hard fail if we encounter a version lower than what
we have in the DB.
A CLI will be added in a later commit that allows users to explicitly
do that.
This sets up the testing infrastructure to test migrations we are
doing.
It's done on a in memory database directly, we are only interested
in the statements themselves and it's easier than to try and
inject a prepared db into the store.
We do add some dummy data though to make sure we actually execute
the things as we expect.
This just repeats the hard coded values from the code, which
is not helping.
We need to touch that test whenever we modify the sql which is
undesired and it doesn't test any useful functionality.
Any error that may ensue would hopefully be tracked by the other
test.
The only reason we accepted a client was that so we have access
to the next message id when we need it.
So let's accept an id provider function instead.
TL is stupid and doesn't wait for message{Provider,Storage} to
settle before it starts using the store.
While this should be fixed globally, we can hack around the problem
by pushing everything onto the call stack and hope that we'll eventually
finish the setup before we blow the stack.
Message stores are more complicated that a sync "fire and forget"
API allows for.
For starters, non trivial stores (say sqlite) can fail during init
and we want to be able to catch that.
Second, we really need to be able to run migrations and such, which
may block (and fail) the activation of the store.
On the plus side, this pushes error handling to the caller rather
than the stores, which is a good thing as that allows us to eventually
push this to the client in the UI, rather than just logging it in the
server on stdout
* Remove config from Helper
Helper is the usual util grab bag of useful stuff.
Somehow the config ended up there historically but
structurally that doesn't make any sense.
* Add cert folder to prettier ignore file
* Extend test coverage to the `search` function.
* Test sort order of messages from `getMessages` and `search`
* Move reversal of `search` results from Vue to messageStorage.
* Remove unnecessary uses of `sqlite.serialize` in tests.
* Return promises from test functions where possible.
