Decaf Blog Data pipelines, open-source tooling, reverse engineering, and systems notes

varmq v1.8.0 - Worker Error Handling for Queue Operators

4 min read

goptics/varmq v1.8.0 was published on July 4, 2026, with a worker error handling change that matters more than the small release size suggests. The release adds a callback based error handler for workers, adjusts the next queue picker error flow, and keeps benchmark history in Cloudflare R2 for operators who care about queue behavior over time. It is not marked as a prerelease.

The full release notes and downloads are on the GitHub release page.

Worker errors get a callback path

For queue workers, the main runtime change is the new callback based error handler from PR 81. The notes do not spell out the handler signature, so this should be read as an integration point to inspect before rollout, not as a full operations guide.

For data pipelines, this is the kind of change that usually matters at the boundary between message intake and retry policy. Worker errors can be routed into logging, metrics, alerting, or a local retry decision without forcing every caller to treat worker failure as the same shape of event. In ELT tasks that pull from APIs or push small batches, that can make it easier to separate transient remote failures from payload or queue state issues.

This also makes testing more concrete. A worker can be exercised with a known error path, and the callback can be asserted as part of the worker contract. That is useful in ingestion jobs where a failed item should not look the same as a failed queue poll or a failed shutdown.

Queue picker errors are now more visible

v1.8.0 also changes the next queue picker error flow in PR 80. The release notes call this a refactor, not a feature, so the safe reading is that behavior around queue selection errors has been reshaped internally.

That is still relevant for platform teams. Queue selection sits in the path that decides which work runs next. If an error from that path is swallowed, delayed, or turned into a generic worker failure, operators lose useful signal. This release appears to make that error path more explicit, though the notes do not claim a new public API.

Treat this as a regression test target. Cover empty queue sets, bad queue state, and worker shutdown paths if those cases exist in your deployment. The change is small in the notes, but it touches the point where queue state becomes worker action.

CI, benchmarks, and docs stay modest

Two changes are about project maintenance, but they still affect consumers. PR 83 limits tests to Go file changes. That reduces wasted CI on docs only changes, though it also means non Go assets need their own checks if they ever become part of runtime behavior.

PR 84 stores benchmark data in Cloudflare R2. For a message queue library, keeping benchmark history is useful only if the data is compared across releases and not treated as a badge. The release notes do not publish benchmark numbers, so there is no throughput claim to repeat here. The useful bit is that benchmark results now have an external home, which makes long term performance drift easier to observe if the project exposes that data consistently.

The documentation change in PR 82 adds a logo and converts the README header to HTML with badges and a description. That is mostly presentation. It can still help new users identify the package, the status checks, and project scope faster, but it does not change queue semantics.

Upgrade notes

No breaking change or migration step is listed in the release notes. Because worker error handling and queue picker error flow are both close to runtime behavior, run the release against a staging workload before using it in a queue backed ingestion path.

Focus tests on worker failure callbacks, queue selection after an error, and any metrics or logs that depend on worker error text. The GitHub release page is the source to check for updates if the project adds more detail.

Where to get it