DEV Community: Yusuf İhsan Görgel

A Redis Task Queue in Dart: Weighted Polling, Dead Letters, and One Nasty Empty-Poll Bug

Yusuf İhsan Görgel — Wed, 08 Jul 2026 12:39:12 +0000

I recently built a small Redis-backed task queue for server-side Dart, because the ecosystem didn't have a maintained one. In a companion post I wrote about why — the gap on pub.dev, what I ported from Go's Asynq, and what I deliberately left out of a first version.

This post is the other half: how it actually works. It's about 360 lines of Dart, and the interesting parts are all in how three Redis commands get used. If you've ever wondered what's under a task queue, this is a small enough one to hold in your head.

flowchart LR
    P["producer"] -->|LPUSH| Q["queue list<br/>rtq:pending"]
    Q -->|"weighted BRPOP"| W["worker"]
    W -->|success| D["done"]
    W -->|throw| Rt["retry"]
    Rt -->|"attempt < max"| Q
    Rt -->|exhausted| DL[("dead-letter<br/>rtq:dead")]

The data model: a Task the user sees, an Envelope Redis stores

The user-facing unit is a Task — a type string plus a JSON payload:

class Task {
  Task(this.type, this.payload);
  final String type;                     // routes to a handler
  final Map<String, dynamic> payload;    // whatever the handler needs
}

The split is deliberate: the code that enqueues and the code that processes only agree on a string and a shape. They don't share a class hierarchy, and they can live in different processes.

But the Task isn't what gets stored. Redis stores an Envelope — the task plus the metadata the queue needs to run and retry it:

class Envelope {
  final String id;
  final Task task;
  final String queue;
  final int maxRetries;
  int attempt;             // incremented on each retry
  String encode() => jsonEncode({ /* id, task, queue, max_retries, attempt */ });
}

attempt is the only mutable field, and it's the whole retry state machine: bump it each failure, give up when it passes maxRetries. Keeping run-state on the envelope (not in a separate Redis key) means a job is one self-contained string — nothing to clean up, nothing to get out of sync.

Enqueue is one LPUSH

Producing a task is deliberately trivial — a single write:

Future<String> enqueue(Task task, {String queue = 'default', int maxRetries = 5}) async {
  final id = _newId();
  final env = Envelope(id: id, task: task, queue: queue, maxRetries: maxRetries);
  await _command.send_object(['LPUSH', _keys.pending(queue), env.encode()]);
  return id;
}

LPUSH pushes the encoded envelope onto the head of a Redis list. Because the worker pops from the tail (more on that next), head-push + tail-pop gives you FIFO ordering for free — first in, first out, which is what you want for a job queue. Since it's a single command, you keep one client alive for the app's lifetime and reuse it; there's nothing to pool.

The worker: weighted polling with one BRPOP

This is the part with actual design in it. The worker drains multiple queues, and it drains them by weight so a flood of low-priority work can't starve the important stuff.

The trick is almost embarrassingly simple. You expand the weights into a repeated list of keys:

List<String> _weightedOrder() {
  final order = <String>[];
  _queues.forEach((queue, weight) {
    for (var i = 0; i < weight; i++) order.add(queue);
  });
  return order;   // {'critical':6,'default':3,'low':1} -> [crit×6, default×3, low×1]
}

Then you hand that whole list to a single BRPOP:

final keys = order.map(_keys.pending).toList();
final res = await _command.send_object(['BRPOP', ...keys, '1']) as List;

BRPOP key1 key2 ... timeout is a blocking right-pop across many keys at once. It scans the keys left to right and returns from the first one that has an item. Because critical appears six times near the front of the list, it gets first refusal six times over before low gets a look — that's the weighting, and Redis does it atomically. No priority field, no sorting, no second data structure. The blocking part also means an idle worker sleeps in Redis instead of hot-looping, so an empty queue costs you nothing.

The bug: an empty poll doesn't return null

Here's the one that cost me real time, and it's the reason I don't trust a queue I haven't run idle.

BRPOP with a timeout has two outcomes. A hit returns [key, value]. A timeout — no job for a full second — returns nothing. I assumed "nothing" meant null. It doesn't:

// WRONG: this branch never runs
if (res == null) continue;
final env = Envelope.decode(res[1] as String);   // boom, every idle second

The Redis client hands back [null] on timeout — a one-element list whose single element is null, not a bare null. So res == null was never true, and every idle second the worker tried to read res[1] off a list of length one and threw. An idle worker — the normal state — was crashing on a schedule.

The fix is one line:

if (res.isEmpty || res.first == null) continue;
await _process(Envelope.decode(res[1] as String));

I only found it because a test spins up a real worker against a real Redis and lets it sit with an empty queue. Unit tests with a mocked client would have sailed right past it — the mock would have returned whatever I thought BRPOP returns, which was the wrong thing. The boring states (idle, empty, timed-out) are where the real bugs live.

Retry or dead-letter

Processing routes by type and treats any throw as a failure — including "no handler registered," so a wiring mistake surfaces loudly instead of silently dropping jobs:

Future<void> _process(Envelope env) async {
  final handler = _handlers[env.task.type];
  try {
    if (handler == null) throw StateError('no handler for "${env.task.type}"');
    await handler(env.task);
  } catch (_) {
    await _retryOrDeadLetter(env);
  }
}

And the retry path is where a job's life ends one of two ways:

Future<void> _retryOrDeadLetter(Envelope env) async {
  if (env.attempt >= env.maxRetries) {
    await _command.send_object(['LPUSH', _keys.deadLetter(), env.encode()]);
    return;                       // out of tries -> dead-letter list
  }
  env.attempt++;
  await _command.send_object(['LPUSH', _keys.pending(env.queue), env.encode()]); // back on its queue
}

Two honest caveats I put in the README rather than hide:

The re-enqueue is immediate — no backoff. A production version delays it with a sorted set scored by a "run-after" timestamp. I left that out of 0.1.0 to keep the core path readable; it's the first thing on the list to add.
A dead-letter list, not silent death. Once retries are exhausted the envelope goes to <prefix>:dead so you can inspect what failed, instead of the job vanishing or looping forever.

That's the whole thing

Three commands — LPUSH to produce, BRPOP to consume, LPUSH again to retry or dead-letter — plus a repeated-key trick for weighting and an envelope that carries its own retry count. No magic, which is the point: a queue small enough to read end to end is a queue you can actually trust in front of your request path.

The package is redis_task_queue on pub.dev, source on GitHub. If you want the decisions behind it — what I took from Asynq and what I refused to copy into a first version — that's in the companion post.

I Built an LLM Filter That Prefers Silence Over Slop — and the Eval Harness That Keeps It Honest

Yusuf İhsan Görgel — Tue, 07 Jul 2026 23:18:52 +0000

Last month, curl paused security reports for a stretch because the queue had filled with AI-generated slop — plausible-looking bug reports that were wrong. It's the same complaint the Stack Overflow survey put a number on: the top frustration with AI output isn't that it's useless, it's that it's almost right. Confidently, expensively, almost right.

I ran into a smaller version of this problem a while back, building a pipeline that pulls financial news from a stream, decides which items actually matter, and forwards only those. The failure mode that mattered wasn't missing a story. It was forwarding a wrong one. A false positive here isn't a minor annoyance — it's a signal someone might act on.

So I built the whole thing around one goal: prefer silence over slop. Here's how, and — more importantly — the eval harness that keeps it honest, because a filter you can't measure is just a vibe.

Why false positives cost more than false negatives

Most classification tutorials optimize for balanced accuracy, or F1, treating a miss and a false alarm as roughly equal mistakes. For a lot of problems that's fine. For this one it's exactly wrong.

If the pipeline stays quiet on a real story, the cost is: someone reads it somewhere else, a few minutes later. Annoying, recoverable.

If the pipeline forwards a wrong story — a misread number, a rumor stated as fact, a stale headline — the cost is: someone trusts it because the pipeline is supposed to have filtered it. The whole value of a filter is that passing through means something. One confident wrong answer devalues every correct one before it.

So the design target isn't "high accuracy." It's a false-positive rate low enough that a pass-through is trustworthy, accepting that we'll stay silent on borderline cases. Recall is the thing I'm willing to trade.

The gating pipeline

The filter isn't one model call. It's a chain of cheap-to-expensive gates, and the cheap ones exist to keep the expensive one from ever being the single point of judgment.

Canonicalize. Normalize the text, strip boilerplate, extract entities. Nothing clever — this just makes later steps deterministic.
Hard rules first. Regex and lookup gates for the things that don't need a model: known-noise sources, duplicate hashes, items missing a required entity. If a hard rule can reject it, no model runs. Cheap, deterministic, and it shrinks the surface the model has to be right about.
The model classifies — but it can abstain. This is the core move. The prompt doesn't force a binary. It's allowed to return uncertain, and uncertain is treated as reject, not pass. A model that isn't sure is, for this pipeline, a model saying "stay silent."
Post-veto. Even a confident pass gets checked against the extracted facts. If the model's justification references a number or entity that isn't actually in the source text, it's vetoed. This is the step that catches the "almost right" — the confident summary of a thing that was subtly not said.

The asymmetry is baked in at every gate: the default is silence, and passing requires clearing all of them.

The part everyone skips: the eval harness

Here's the thing about a filter tuned for low false positives — you cannot tell if it's working by looking at it. It's quiet by design. Quiet because it's good and quiet because it's broken look identical from the outside.

So the filter isn't the real artifact. The eval harness is.

It's a golden dataset — hand-labeled items, each marked should-pass or should-reject, including the nasty ones: the almost-right, the plausible-but-stale, the technically-true-but-misleading. Every change to a prompt, a rule, or a threshold runs against it and reports:

False-positive rate — the number I actually care about, gated hard. A change that lowers FP-rate but tanks recall is a conversation. A change that raises FP-rate fails the build, full stop.
Recall — tracked, not gated, so I can see the cost of my strictness and decide if it's too much.
Per-category breakdown — because "it got worse" is useless; "it got worse on stale-headline cases" is a lead.

This is the discipline the AI-slop stories are missing. The problem in those threads isn't that people used a model. It's that they shipped its output without a regression suite that would have caught the slop before a human had to. An LLM step without an eval harness is an untested function you deploy to production and hope about.

Treating evals like tests changed how I make changes. A new prompt idea isn't "better" because it reads better. It's better if it moves the FP-rate down without moving recall down more than I'll accept — and I have a number for that, before it ships, every time.

What I'd tell someone starting

Decide which error is expensive before you tune anything. It changes every threshold downstream.
Let the model abstain, and make abstain mean "no." A forced binary manufactures confidence you didn't earn.
Build the golden dataset first, and put the ugly cases in it. The average case is easy; the harness earns its keep on the almost-right ones.
Gate the metric you care about in CI. If a regression on it doesn't fail the build, it will ship.

None of this is exotic. It's just testing, applied to the one part of the system we keep exempting from testing because it's a model. The model isn't special. It's a function with a bad day ahead of it, and the harness is how you find out before your users do.

Turning a Portfolio Effect Into a Zero-Dependency Flutter Package

Yusuf İhsan Görgel — Mon, 06 Jul 2026 17:51:08 +0000

A while ago I wrote about the spatial grid particle system in my Flutter Web portfolio. The trick was keeping the connecting-line effect close to O(n) instead of the O(n²) you get from checking every pair. After that post, a few people asked if they could use the widget in their own projects.

Short answer: they couldn't. The widget was wired into my app. That bothered me, so I extracted it into a package: constellation_particles.

This post is not about the algorithm again — the first post covers that. It is about the extraction itself: what it takes to turn a widget from your own app into something a stranger can install.

The Problem: It Looked Reusable, But It Wasn't

On paper the widget was self-contained. One file, a CustomPainter, a particle list. But the constructor told a different story. It reached into a GetX controller for the current scene, read an accent color and a speed from it, and listened with ever():

final director = Get.find<SceneDirector>();
_config = director.blendedConfig.value;
_configWorker = ever(director.blendedConfig, (cfg) {
  _config = cfg;
});

Drop this into an app without a SceneDirector and it throws immediately. So the widget forced two things on every user: GetX, and my scene abstraction. Neither one has anything to do with drawing particles.

What It Actually Needed

I checked what the widget really reads from that config. Two values: a color and a speed multiplier. That's it. A full state-management dependency existed to deliver one Color and one double.

So they became constructor parameters, together with everything else you may want to tune:

const ConstellationParticles({
  this.particleCount = 100,
  this.color = const Color(0xFF64FFDA),
  this.speed = 1.0,
  this.connectionDistance = 120.0,
  this.repulsionRadius = 200.0,
  this.repulsionForce = 50.0,
  this.seed = 42,
});

The ever() listener became didUpdateWidget. If the color or the count changes, the widget reacts — the normal Flutter way. No plugin, no controller, nothing to register at app start. The dependency list is just Flutter.

I think this part is underrated when people publish packages: a package that brings a state-management library with it is not a small package, no matter how few lines it has. The goal was that using it costs you nothing extra.

What I Kept

The extraction was mostly deleting coupling. But a few parts were worth keeping, and they are easy to lose in a rewrite:

Lifecycle-aware — the ticker pauses when the app is hidden or backgrounded. No frames burned in a tab nobody is looking at.
Accessibility — particle count drops to half when the platform asks for high contrast.
Repaint gating — shouldRepaint checks a generation counter, so the painter repaints only when the simulation actually moved. Paints and the glow gradient are cached, not rebuilt every frame.

Nothing here is clever. But it is the difference between a demo and something you can leave running behind real content.

Using It

Stack(
  children: [
    const Positioned.fill(child: ConstellationParticles()),
    yourContent,
  ],
)

GitHub: https://github.com/Yusufihsangorgel/constellation_particles
pub.dev: https://pub.dev/packages/constellation_particles

If you build something with it, I would like to see it. If you find a bug, the issue tracker is open. Would love feedback, especially on the API surface — is this parameter set enough, or already too much?

Building a Spatial Grid Particle System in Flutter Web

Yusuf İhsan Görgel — Fri, 03 Apr 2026 16:09:50 +0000

I recently built my developer portfolio entirely in Flutter Web. Instead of using a template, I wanted something with real engineering depth — cinematic backgrounds, interactive particles, and proper architecture.

The most interesting technical challenge was the particle system. Here's how I solved the performance problem.

The Problem: O(n²) Neighbor Lookups

A constellation particle effect draws connecting lines between nearby particles. The naive approach checks every pair:

// O(n²) — kills performance at 50+ particles
for (var i = 0; i < particles.length; i++) {
  for (var j = i + 1; j < particles.length; j++) {
    if (distance(particles[i], particles[j]) < threshold) {
      drawLine(particles[i], particles[j]);
    }
  }
}

With 100 particles, that's 4,950 distance checks per frame. At 60fps, it's choppy.

The Solution: Spatial Grid Hashing

Divide the viewport into cells. Each particle registers in its cell. To find neighbors, only check the 9 surrounding cells:

final class _SpatialGrid {
  final double cellSize;
  final Map<int, List<_Particle>> _cells = {};

  int _key(double x, double y) {
    final cx = (x / cellSize).floor();
    final cy = (y / cellSize).floor();
    return cx * 10000 + cy;
  }

  void insert(_Particle p) {
    (_cells[_key(p.x, p.y)] ??= []).add(p);
  }

  List<_Particle> neighbors(double x, double y) {
    final cx = (x / cellSize).floor();
    final cy = (y / cellSize).floor();
    final result = <_Particle>[];
    for (var dx = -1; dx <= 1; dx++) {
      for (var dy = -1; dy <= 1; dy++) {
        final cell = _cells[(cx + dx) * 10000 + (cy + dy)];
        if (cell != null) result.addAll(cell);
      }
    }
    return result;
  }
}

Now each particle only checks ~9 cells × ~5 particles = ~45 checks instead of 100. O(n) instead of O(n²).

The Full System

The particle system has more going on:

Cursor repulsion — particles within 200px of the mouse get pushed away with spring physics
Connection lines — drawn between particles within 120px, with opacity based on distance
Scene-aware — particle density and speed change based on which section you're scrolling through (controlled by a SceneDirector state machine)
Lifecycle-aware — animations pause when the browser tab is hidden
RepaintBoundary — isolated from the rest of the widget tree to avoid unnecessary repaints

The Cinematic Background Stack

The portfolio layers 7 visual elements:

Dark base color
Animated mesh gradient (Lissajous-curve blob movement with mouse parallax)
Film grain overlay (pre-rasterized 256×256 texture via toImageSync)
Constellation particles (spatial grid system)
Vignette overlay (per-scene intensity)
Scrollable content
Fixed UI (sidebars, scroll dots, cursor)

Each scene (Hero, About, Experience, Projects, Contact) maps to a movie color palette — Blade Runner 2049, Dune, The Matrix, Spider-Verse, and Interstellar. A SceneDirector controller crossfades between them with 200px blend zones.

Architecture

The project uses Clean Architecture with Dart 3.x patterns:

abstract interface class for domain contracts
final class on all concrete classes
switch expressions and case when pattern guards
GetX for reactive state (scroll, scene, language, sound controllers)
185 automated tests

Try It

Live demo: developeryusuf.com

GitHub: Yusufihsangorgel/Flutter-Web-Portfolio

It's fully forkable — change your JSON data, photo, and meta tags. All content is data-driven.

Would love feedback, especially on the particle system performance and the scroll-driven scene architecture.

Built with Flutter 3.41, Dart 3.7, zero external UI dependencies.