Prepare 0.5.8

Cargo.lock

@@ -1813,7 +1813,7 @@ dependencies = [
 
 [[package]]
 name = "pict-rs"
-version = "0.5.7"
+version = "0.5.8"
 dependencies = [
  "actix-form-data",
  "actix-web",

Cargo.toml

@@ -1,7 +1,7 @@
 [package]
 name = "pict-rs"
 description = "A simple image hosting service"
-version = "0.5.7"
+version = "0.5.8"
 authors = ["asonix <asonix@asonix.dog>"]
 license = "AGPL-3.0"
 readme = "README.md"

README.md

@@ -220,8 +220,7 @@ More information is available in the [Ubuntu and Debian docs](./docs/ubuntu-and-
 
 ##### Compile from Source
 pict-rs can be compiled from source using a recent version of the rust compiler. I do development
-and produce releases on 1.72. pict-rs also requires the `protoc` protobuf compiler to be present at
+and produce releases on 1.75
-build-time in order to enable use of [`tokio-console`](https://github.com/tokio-rs/console).
 
 Like the Binary Download option, `imagemagick`, `ffmpeg`, and `exiftool` must be installed for
 pict-rs to run properly.

pict-rs.nix

@@ -11,7 +11,7 @@
 
 rustPlatform.buildRustPackage {
   pname = "pict-rs";
-  version = "0.5.7";
+  version = "0.5.8";
   src = ./.;
 
   cargoLock = {

releases/0.5.8.md

@@ -0,0 +1,84 @@
+# 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.