This makes each reply chain load completely before loading the next
chain, instead of the current behavior that loads all replies of one
depth before loading the next "layer".
This won't make much of a difference *now*, but should result in more
intuitive behavior when live updating of newly loaded replies gets
implemented.
Instead of backfilling every note we come across that has a reply
collection, only schedule a backfill job if someone wants to see the
replies (on GET MastoAPI /context, or Iceshrimp API /descendants)
Reply backfilling is also done on a ThreadIdOrId basis as opposed to the
previous way of backfilling individual notes. This allows us finer
grained control over the recursion and frees up the job queue, alongside
allowing for easier implementation of context collection backfill in the
future (by mapping each context collection to a thread)
---
Currently, note threads are implicit based on the "threadId" column of a
note, which can be null (where it's the same as the note's "id")
This commit turns note threads into an actual entity, and as a part of
that, makes "threadId" non-nullable (by specifically setting it to "id"
for those cases)
This is done to attach extra metadata to the entire thread, currently
just the time of when it was last backfilled, but more may be added in
the future (the context collection associated with this thread, for example)
---
The data format for backfill jobs have backwards-incompatibly changed
since the introduction of the feature. We can drop all old jobs without
causing too much trouble as they will be re-scheduled on demand
---
Signed-off-by: Laura Hausmann <laura@hausmann.dev>
There's no performance difference between fetching just the private key from the user_keypair table and the previous caching implementation, so there's no point in keeping it in the cache.
This commit lays the groundwork for a user-configurable image processing pipeline. It has exactly the same behavior as the old ImageProcessor, just modular & compartmentalized. It also adds support for AVIF & JXL encoding, though no code paths call it just yet.
This:
- improves performance (because we can check them in batches)
- improves efficiency (because we don't create deliver jobs that get discarded immediately)
- allows us to check whether the activity is an ASFollow & let it through if it is (for skipped instances filter only)
We still check for blocked instances in the deliver queue in case a deliver job is created via another code path.
