About

taskfused.com is the home of TaskFused, a small Go engine that runs duplicate requests once. You give each piece of work a name. The first request with that name creates a durable operation; every equal request after it joins that operation and gets the same result, whether it comes from the same program, another process on the machine, or a retry after a timeout. The operations live in a local SQLite file, so they outlast crashes and restarts.

Why It Exists

Plenty of work gets asked for twice. A user double-clicks Export. Ten dashboards ask for the same monthly report at nine in the morning. A client times out and retries while the first request is still running. Each copy burns the same CPU, the same API credits and the same database time, and sometimes the copies step on each other.

Inside one Go process the usual fix is singleflight: callers asking for the same key share one call. It’s a good tool, and it forgets everything when the process exits. A crash or a deploy loses the work in flight, and a second process never sees the first one’s call. TaskFused keeps the same idea and writes it down: the operation, its attempts and its result go into SQLite before anyone is told they exist.

How It’s Built

• On SQLite. One file per host, in WAL mode with every change flushed to disk (synchronous = FULL). Each step of an operation is one transaction.
• Named work. An operation is identified by namespace, handler, handler version and key. Same name and same input means the same operation. Same name with different input is refused as a conflict, so two different jobs can never share a result by accident.
• Leases. A worker holds each attempt for a limited time and renews it while it works. If the worker dies, the lease runs out and another worker picks the job up under the same operation ID. A late result from the dead worker is rejected.
• Three ways in. A Go package to embed, a taskfused command, and an HTTP API on the loopback address with a read-only status page.
• Tested by breaking it. The tests kill real worker processes mid-job, force storage failures at every write, and check that nothing ends up half-saved. The results are published with the code.

License

All the code is open source under the Apache License 2.0, on GitHub. You can use it, change it and build it into your own products.

Questions People Ask

Is it really free?

Yes. TaskFused is free to use, and the code is free to take under the Apache License 2.0.

Does a job ever run twice?

It can. TaskFused runs each operation at least once, and it doesn’t promise “exactly once”. If a worker dies after doing the work but before saving the result, the job runs again on another worker. Work with outside effects, such as sending money or an email, should use the operation ID as its own idempotency key. Joining requests never cause an extra run; only crashes and retries do.

How is it different from a job queue?

A queue takes every job you give it. TaskFused looks at the job’s name first: if that work already exists, you get the existing operation and, once it’s done, its stored result. It does have workers, leases and retries like a queue, because shared work still has to get done.

Can workers run on other machines?

Not yet. Version 0.1 is for one host: the SQLite file sits on a local disk, and any number of processes on that machine can share it. The HTTP API listens on the loopback address only.

Which languages can use it?

Go programs embed it. Any language can submit work and wait for it through the local HTTP API or the taskfused command. Handlers, the code that does the work, are written in Go.

What’s the status page?

taskfused serve shows a small read-only page with a namespace’s counts and one operation’s state, whether its result is stored, and its history. It has no JavaScript and no login, which is one reason it stays on the loopback address.

Can I suggest something?

Please do. The contact page has the address.