You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 419f9db
Browse filesBrowse the repository at this point in the historyBrowse files
fix(void): log queue handler errors instead of dropping them (#629)
## Summary
When a queue handler throws, its error is never logged. The generated
`__processQueue` catches it without binding it (`} catch { __ok = false;
}`), so the reason is lost on every path:
- Native Cloudflare consumers: the Worker's `queue()` throws a new
`Error("queue: Handler failed.")`, and Workers Logs and `void project
logs` show only that.
- Dev: `/__void/queue` answers `{"ok":false}`, and nothing reaches the
terminal.
- Void Cloud: the relay gets a 200 `{"ok":false}` and retries the batch,
and nothing is logged.
The generated `scheduled()` already logs a failing job's error (`[void]
Scheduled job … failed for cron "…"`). `__processQueue` in
`packages/void/src/router/compile.ts` now does the same for queue
handlers before marking the batch failed, which covers all three paths.
When no handler matches the queue, `__processQueue` returned the reason
only as `error`, which the native `queue()` dropped and the Void Cloud
relay ignores, so it now logs that reason too. `handleQueueRelay` in
`packages/void/src/cli/wrapper.ts` had the same `catch` and now logs
too. The wrapper's native `queue()` already lets errors through, and the
framework dev trigger already logs them (`[void] queue handler threw:`).
The thrown `queue: Handler failed.`, the `{ ok: false }` result and the
ack/retry decisions are unchanged. `docs/guide/queues.md` now says the
handler's error is logged.
## Repro
1. `queues/fail.ts`:
```ts
import { defineQueue } from 'void';
export default defineQueue(async () => {
throw new Error('boom');
});
```
2. Start the dev server, then send it a message with the token it
prints:
```sh
curl -X POST http://localhost:5173/__void/queue \
-H "x-void-dev-trigger: <token>" \
-d
'{"queue":"fail","messages":[{"id":"1","timestamp":0,"body":{},"attempts":1}]}'
```
- Before: the response is `{"ok":false}`, and `boom` is logged nowhere.
- After: the response is unchanged, and the terminal shows `[void] Queue
handler queues/fail.ts failed for queue "fail": Error: boom` with its
stack. A message sent through the queue binding (Miniflare's native
delivery) logs the same line.
## Tests
- `packages/void/test/integration/queue-dispatch.test.ts`: the error a
handler throws reaches `console.error` as the same object, with its file
and queue, through `__processQueue` and through the native `queue()`.
Both also log the reason for an unknown queue.
- `packages/void/test/unit/wrapper.test.ts`: the same for the wrapper's
HTTP relay.
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
-`batch.ackAll()`: acknowledge all messages in the batch
77
77
-`batch.retryAll(options?)`: retry all messages in the batch
78
78
79
-
The first call wins for each message. Calling `ack()` after `retry()`, or the reverse, does nothing. Messages with no explicit decision are acknowledged if the handler succeeds, or retried if it throws.
79
+
The first call wins for each message. Calling `ack()` after `retry()`, or the reverse, does nothing. Messages with no explicit decision are acknowledged if the handler succeeds, or retried if it throws. The handler's error is logged, so you don't need to catch errors just to log them.
80
80
81
81
The `timestamp` field on each message is a `Date` object.
0 commit comments