pict-rs/releases/0.5.8.md
2024-03-10 22:48:11 -05:00

4.1 KiB

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

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.