fix: use nonempty() for retry array type to match runtime validation

[claygeo]

Problem

EnqueueJobOptions.retry is typed as (number | string)[] which allows empty arrays, but the Zod schema at src/client/index.ts:132 enforces .min(1) at runtime. Passing an empty retry array fails with:

body/retry must NOT have fewer than 1 items

The type doesn't reflect this constraint because Zod's .min() does not change the inferred type.

Solution

Replace .min(1) with .nonempty(), which both:

• Enforces the minimum at runtime (same behavior)
• Narrows the inferred TypeScript type to [T, ...T[]] (at least one element)

The .max(10) constraint is preserved.

- retry: z.array(timeDuration("retry")).min(1).max(10).optional(),
+ retry: z.array(timeDuration("retry")).nonempty().max(10).optional(),

Changes

• src/client/index.ts — Replaced .min(1) with .nonempty() on retry schema

Closes #1167

[netlify]

👷 Deploy request for quirrel-development-ui pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	bd9ff32

[netlify]

👷 Deploy request for quirrel-docs pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	bd9ff32

[claygeo]

Reviving this one. The bug in #1167 still reproduces on current main: the public EnqueueJobOptions.retry type accepts [], but the runtime schema rejects it ("Should have at least 1 items").

Verifying it surfaced something though, the original one-line schema change (.min(1) -> .nonempty()) isn't sufficient on its own:

1. It only narrows the schema's inferred type. The type users actually consume is the hand-written EnqueueJobOptions interface (retry?: (number | string)[]), which was untouched, so an empty array still type-checks at the call site.
2. In isolation it also breaks tsc: enqueue() / enqueueMany() pass that interface (a plain array) into payloadAndOptionsToBody, whose param is now the non-empty tuple, so (string | number)[] is no longer assignable (TS2345 at both call sites). There's no typecheck step in CI, so it slipped through.

So I pushed a follow-up commit (bd9ff32) tightening the interface to retry?: [number | string, ...(number | string)[]]. Now the public type rejects retry: [] at compile time, matching runtime, and tsc --noEmit is clean again. Ran the client retry and schema-checks suites locally, both green.

One intended consequence: this tightens a public type, so code that builds retry as a general number[]/string[] variable will now need a non-empty tuple or a literal. That's the behavior #1167 asks for.

(Forward-note: whenever zod moves to v4, .nonempty() no longer changes the inferred type, so the schema side would switch to z.tuple([...], rest). Not relevant for the pinned v3 here.)

Could a maintainer take another look when you get a chance? Happy to adjust.