denis256 notes and projects

varmq v1.8.0 was published on July 4, 2026, with a new callback based worker error handler and a small set of CI, benchmark, and documentation changes. For engineers checking what changed in varmq v1.8.0, the main user facing item is better control over worker failure handling, backed by cleanup in the queue picker error path.

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

Worker errors get an explicit callback path

The most useful change in this release is the worker error handler added in PR 81. The release notes describe it as a callback based error handler for workers.

That matters because worker failures are not just log lines in queue based systems. They often decide retry behavior, alerting, metrics, and how much context an operator has when a job does not finish cleanly. A callback gives application code a named place to react to those errors instead of pushing that logic into scattered call sites.

The notes do not spell out the exact callback signature, so this is not the place to invent an API example. The practical reading is simpler: if a varmq worker can fail in ways your service needs to observe, v1.8.0 is the release to inspect before adding more local wrapper code.

Queue picker errors were refactored

The next queue picker error flow changed in PR 80. The release notes call this a refactor, not a new feature.

That distinction is useful. It suggests the maintainers touched internal control flow around how the next queue is picked and how errors move through that path. For users, the expected value is less about a new knob and more about sharper behavior around a part of the system that can make worker scheduling awkward when it fails.

Queue selection is easy to ignore until there are multiple queues and one path starts returning errors. Then unclear error flow turns into noisy handling code. This release appears to tighten that area while keeping the visible release surface small.

CI now spends less time on irrelevant changes

The CI update in PR 83 changes test execution so tests run only on Go file changes. For a Go project, that is a blunt but useful filter.

It means documentation only edits and other non Go changes should not spend CI minutes on a test suite that cannot be affected by those files. The tradeoff is the usual one: path based CI rules need to stay honest as the repository grows. If build scripts, generated files, or fixtures start affecting Go behavior later, those paths need to be included too.

The release also adds benchmark data storage in Cloudflare R2 via PR 84. That is operator adjacent more than user facing. It gives the project a place to keep benchmark output over time, which is useful when maintainers need to compare changes instead of relying on a single local run.

Documentation gets a clearer front door

PR 82 adds a logo and converts the README header to HTML with badges and a description. This is not runtime behavior, and it should not be dressed up as one.

It still matters for a small infrastructure library. The README is where most developers decide whether a queue library is alive, tested, and worth evaluating. Badges, a clearer description, and a recognizable header reduce the amount of digging needed before someone reads the API or tries the package.

The release notes do not mention breaking changes, migrations, or deprecations. It is also not marked as a prerelease. Treat v1.8.0 as a regular feature and maintenance release, then review the worker error handling change if your application depends on custom worker failure behavior.

Where to get it

• Release page URL: GitHub release page
• Repo URL: goptics/varmq
• Tag name: v1.8.0