Make the cleaner available to users by exposing it as a subcommand
to thelounge storage.
This is recommended to be run whenever the storage policy significantly
changes in a way that makes many messages eligible for deletion.
The cleaner would cope, but it'll be inefficient and can take many hours.
Due to how storage works in sqlite, the space would not actually be
given back to the OS, just marked for future writes.
Hence this also runs a vacuum to compact the DB as much as it can.
Once this is getting hooked up, it'll periodically delete old
messages.
The StoragePolicy can be chosen by the user, currently there's
two versions, delete everything based on age is the obvious.
The other is for the data hoarders among us. It'll only delete
message types which can be considered low value... Types with
a time aspect like away / back... joins / parts etc.
It tries to do that in a sensible way, so that we don't block
all other db writers that are ongoing.
The "periodically" interval is by design not exposed to the user.
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
A user reported in the IRC chan that installing packages fails with
```
2023-12-13 20:02:34 [INFO] Installing thelounge-theme-solarized v1.1.9...
undefined:1
(node:3329) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
^
SyntaxError: Unexpected token '(', "(node:3329"... is not valid JSON
```
Now, this happens as yarn helpfully prints a deprecation warning
that is shown in the stack trace.
Let's assume that we may get non json messages and log them at debug, as we
don't know their severity.
Node apparently throws even on valid ipv6 input in certain environments,
probably due to the DNS server returning SERVFAIL.
Guard against it and fallback with the plain IP
Fixes: https://github.com/thelounge/thelounge/issues/4768
So far the bind config only impacted the IRC connections.
However, nothing in our doc comment says that this is intentional.
> ### bind
> Set the local IP to bind to for outgoing connections.
This commit fixes the leak and uses it for all outgoing requests
as described by the docstring.
Add the ability to migrate our db in the upwards direction.
Use the facility to add primary keys to our messages table.
This should allow work like jumping to messages and the likes.
This also introduces the framework for rollback, without actually
hooking it up.
This should be easy enough to do when the need arises.
Noticed this breakage while trying to install a plugin on 4.4.1-rc2.
```
> semver.default.satisfies("4.4.1-rc2", ">=4.3.0")
false
> semver.default.satisfies("4.4.1-rc2", ">=4.3.0", {includePrerelease: true})
true
```
Network.export() only writes the "type" key if it's a ChanType.QUERY;
so the config on disk has no "type".
This causes it to be undefined when loading, which breaks various other
checks, and then drops it the next time the config is saved.
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.
Keep happy path on the left and try to return as early
as we can to help the reader understand the logic better
The function is too large to be able to quickly scan an if / else
chain and see the function return at the end
Client and ClientManager deal with both 'dehydrated' channels/networks (ie. directly
from JSON configuration) and the 'rehydrated' ones (classes, with socket objects,
message arrays, etc.).
However, because their attributes are similar, both types were used interchangeably,
which becomes an issue when splitting Client's configuration loading into smaller
methods.
We should not mess with irc-framework internals.
Technically we shouldn't even access the connection object,
it's not part of the documented API surface
This introduces the ability to run the migration offline, while
TL is not running as the migrations can take a long time.
The migrate command is added as a `thelounge storage` subcommand.
Reason being that it is expected that more subcommands will follow,
say `thelounge storage clean` to remove partial data from the db.
We want primary keys to never get re-used to so that we
can implement jump to messages / context fetching etc
in the future.
This isn't hooked up yet at all to the rest of the code, only
the schema is changed
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.
Prior to this, the search is still racy but one tends to notice
this only when the DB is large or network is involved.
The user can initiate a search, get bored, navigate to another chan
issue a different search.
Now however, the results of the first search come back in and
hilarity ensues as we are now confused with the state.
To avoid this, keep track of the last search done and any result
that comes in that isn't equal to the active query is garbage and
can be dropped.
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.
The interface should not contain things that aren't the API of the
storage interface.
Further, rename ISqliteMessageStorage to SearchableMessageStorage,
as that's also an implementation detail.
We'll never have a second sqlite backend, so the name seems
strange.
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.
TS type assertions need to be avoided.
The following trivial example demonstrates why
```
type Person = {
name: string;
isBad: boolean;
};
function makePerson(): Person {
const p: Person = {name: 'whatever'} as Person
p.isBad = false
return p // theoretically we are now good, p is a Person
}
```
Should the type ever change though, TS will happily trot along
```
type Person = {
name: string;
isBad: boolean;
omgHowCouldYou: number;
};
function makePerson(): Person {
const p: Person = {name: 'whatever'} as Person
p.isBad = true
return p // p is *not* a Person, omgHowCouldYou is missing
}
```
But we pinky swore to the compiler that p is in fact a Person.
In other words, the types are now wrong and you will fail during
runtime.
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
Currently the realname is set to an advertisement if it isn't explicitly
set by the user.
Some clients started to show the realname as a display name in their
UI, which makes this tedious as you'll end up with gazillion "The Lounge
User" entries.
To avoid this, set the realname to the nick on first connect, so that
it is useful.
Note that this isn't done on nick changes, but only on the initial
connect step.
Fixes: https://github.com/thelounge/thelounge/issues/4527
When a URL is prefixed with a TLS scheme, we should make sure
that the remote provides a valid cert, even just for prefetches.
Else MITM of such a site is trivial.
This probably breaks some people with self signed cert, but the
age where that was acceptable is past. We have free CAs now like
Let's Encrypt.
Make `thelounge install file:~/path/to/package` work rather than
erroring out that the folder doesn't exists.
Probably funny on Windows, but it doesn't hurt either
The message was ordered the wrong way in the TS rewrite.
Old:
+bookworm sent a CTCP request: "chadler" to version
New:
+bookworm sent a CTCP request: "version" to chadler
