pict-rs/releases/0.5.8.md

# pict-rs 0.5.8

## Overview

pict-rs 0.5.8 improves reliability of deletions by allowing background tasks to be retried.
Otherwise changes are fairly minor.

### Changes

- [Improved Task Reliability](#improved-task-reliability)
- [Improved Latency](#improved-latency)


## Upgrade Notes

There is a small repo format migration between 0.5.7 and 0.5.8. For sled it's simply opening a new
tree, for postgre it involves adding a new column to the job_queue table. These changes will
automatically apply when launching pict-rs 0.5.8. Upgrading should be as simple as pulling a new
version of pict-rs.


## Configuration Notes

Check your configurations to make sure you haven't enabled the tokio-console integration unless
you're using it. In my local testing, I've found the console subscriber to use a significant amount
of CPU. While it is very useful for debugging, it shouldn't be used generally in production.

The relevant configuration values are `PICTRS__TRACING__CONSOLE__ADDRESS` with environment variables
or `[tracing.console] address = ""` in the toml.


## Packaging Notes

While I have never recommended packaging pict-rs with non-default crate features enabled, and the
binaries and containers I provide enable only the default features, there are two new crate features
in this release that I would advise against enabling in downstream packaging environments.

The new features are `poll-timer-warnings` and `random-errors`. These are each described below if
you want to learn about them, but as a general recommendation, do not enable non-default features
when packaging pict-rs (yes, i'm talking to you `grawlinson` from the AUR).

The other optional feature, `io-uring`, is considered less stable. It's possible that folks will
find it works alright, and maybe Arch can enable it since they can assume recent kernels, but I
don't personally test much with `io-uring`. It exists mostly as a historical curiosity. Please
consider carefully before enabling io-uring for pict-rs.


## Descriptions

### Improved Task Reliability

pict-rs 0.5.8 adds the ability for tasks to be retried. pict-rs generally spawns background tasks to
handle things like Image deletion or other cleanup operations. Until now, if a background task
failed, the only indication would be a warning that appeared in the logs. These warnings are
generally descriptive and help track the error source, but end users aren't notified, and the repo
or store state can become inconsistant.

With the newly added ability to retry tasks, operations should be completed more reliably. By
default, a failed task will be retried after a 2 minute wait, and if it continues to fail, it will
be retried up to five times. If a task fails after 5 retries, an additional warning will be output
to the log.

In order to test this, I've added a new optional crate feature called `random-errors`, which will
inject errors into various pict-rs operations randomly. This feature should never be enabled in
production scenarios, and two warnings will be printed when launching pict-rs if it was compiled
with this feature enabled.


### Improved Latency

pict-rs 0.5.8 implements a couple new techniques to improve system latency.

1. The postgres connection pooling library has been swapped from deadpool to bb8. Not only does this
    (slightly) improve connection pool access times, but it also means pict-rs is no longer pinned
    to an outdated version of deadpool.
2. Processes like ffmpeg, imagemagick, and exiftool are now spawned from background threads,
    rather than from within the webserver threads. This is notable, since the act of spawning a
    process ends up using a good amount of time, and prevents other requests from being handled
    until the spawning has completed.
3. pict-rs now has the ability to monitor polling times for futures. By default, any task pict-rs
    spawns itself will be monitored to report polling times, and a trait has been added to enable
    easily tracking more polling times in the future. These polling times will appear in the
    prometheus metrics, as well as in logs at DEBUG or TRACE visibility. There's an optional crate
    feature called `poll-timer-warnings` that will upgrade some of these logs to WARN visibility.