Defer queue sends after the response

Use runQueue() for the normal enqueue path. Use deferQueue() when the queue send itself should happen after the current response has already been committed.

What deferQueue() changes

deferQueue() does not change the queue handler. It changes when ViteHub performs the send.

• runQueue() sends during the current request
• deferQueue() schedules the send after the response

That makes deferQueue() useful for non-critical background dispatch where the request should finish first.

Use deferQueue() inside request handlers

import { deferQueue } from '@vitehub/queue'

export default defineEventHandler(() => {
  deferQueue('welcome-email', {
    email: 'ava@example.com',
  })

  return { ok: true }
})

Request-context behavior

deferQueue() reads the current Nitro request context.

• when waitUntil() is available, ViteHub uses it
• otherwise ViteHub falls back to fire-and-forget dispatch

That makes deferQueue() a request-scoped helper, not a generic background worker API.

Pass delivery options only when needed

The common case is a bare payload:

deferQueue('welcome-email', {
  email: 'ava@example.com',
})

Switch to the object form only when you need delivery settings such as a custom job ID or delay:

deferQueue('welcome-email', {
  id: 'welcome-1',
  payload: { email: 'ava@example.com' },
  delaySeconds: 10,
})

When not to use it

Do not use deferQueue() when:

• the send must succeed before you answer the caller
• you are outside a request context
• a plain runQueue() call is already good enough

Related pages

• Runtime API
• Send a job