docket/src/ at main · zzstoatzz.io/docket · Tangled

zzstoatzz.io / docket

0

zig port of github.com/chrisguidry/docket

0

docket / src /

at main 2 folders 5 files

zzstoatzz Reconnect Redis backend after dropped sockets 6w ago

Reconnect Redis backend after dropped sockets

1 month ago

v0: perpetual loop end-to-end against Redis Fills out the skeleton with a working single-worker tick loop: - composite ops in src/backend/redis.zig: scheduleTask, promoteDueTasks, ackMessage, consumeStream, ensureConsumerGroup — each backed by an embedded Lua script (schedule.lua / promote_due.lua / ack.lua) so the state transitions are atomic. - Worker.tick: promote due ZSET entries -> XREADGROUP one -> dispatch via the comptime-erased task shim -> reschedule perpetual BEFORE ack so a perpetual task never silently dies. - examples/perpetual: registers a 2s perpetual task, runs 10s, observes ~5 ticks. Used as the v0 smoke gate. - compose.yml: redis:7-alpine on :6379 for local dev. The bug that gated this: EVAL returns Lua values as RESP bulk strings, not simple strings. The first cut only matched .string in the reply switch, fell through to an error, and the run looked like a hang rather than a clear failure. stringValue() in backend/redis.zig now accepts either variant; scheduleTask/ackMessage route through it. 3/3 tests pass; perpetual example produces 5 ticks in 10s as expected. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2 months ago

Reconnect Redis backend after dropped sockets

1 month ago

Align tests and backend cleanup with Zig 0.16

1 month ago

v0: perpetual loop end-to-end against Redis Fills out the skeleton with a working single-worker tick loop: - composite ops in src/backend/redis.zig: scheduleTask, promoteDueTasks, ackMessage, consumeStream, ensureConsumerGroup — each backed by an embedded Lua script (schedule.lua / promote_due.lua / ack.lua) so the state transitions are atomic. - Worker.tick: promote due ZSET entries -> XREADGROUP one -> dispatch via the comptime-erased task shim -> reschedule perpetual BEFORE ack so a perpetual task never silently dies. - examples/perpetual: registers a 2s perpetual task, runs 10s, observes ~5 ticks. Used as the v0 smoke gate. - compose.yml: redis:7-alpine on :6379 for local dev. The bug that gated this: EVAL returns Lua values as RESP bulk strings, not simple strings. The first cut only matched .string in the reply switch, fell through to an error, and the run looked like a hang rather than a clear failure. stringValue() in backend/redis.zig now accepts either variant; scheduleTask/ackMessage route through it. 3/3 tests pass; perpetual example produces 5 ticks in 10s as expected. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2 months ago

make TaskOptions runtime, not comptime The only fields on TaskOptions are runtime data (perpetual interval, future TTLs / retry policies); forcing the whole record to be comptime meant prefect-server's late_runs couldn't pass an env-derived interval into Perpetual.every_micros without baking the value into a comptime literal. Drops the `comptime` qualifier on the options arg in `register` / `makeTask`. Erased.invoke is still comptime-generated (it has to be — it closes over ParamsType + the user fn) — only the data alongside it relaxes. 5/6 tests pass (memory + redis-gated integration tests unaffected). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2 months ago

Reconnect Redis backend after dropped sockets

1 month ago