Sume waitForJob pollInterval is a floor; next_poll_after_seconds wins

In @sume-com/sdk, waitForJob(jobId, options) polls GET /v1/jobs/{id}/status until the job is terminal. The pollInterval option defaults to 2 seconds and is a floor: the SDK source says the server's next_poll_after_seconds carries queue backoff the client cannot see, so it raises the gap but never shortens it. The default timeout is 20 minutes.

That means you cannot make a slow image or video job poll faster by lowering the interval below what the server asks, and you do not need a custom sleep loop to be polite.

Resulting gap between reads

Logging the real gap

onStatus runs on every read, including the terminal one, so you can print what the loop actually did.

import { createSumeClient, waitForJob } from "@sume-com/sdk";

const client = createSumeClient({ apiKey: process.env.SUME_API_KEY! });
let previous = Date.now();

const job = await waitForJob("job_01J...", {
  client,
  pollInterval: 5_000, // a floor: the gap between reads is never shorter
  timeout: 10 * 60_000,
  onStatus: (status, snapshot) => {
    const gap = Date.now() - previous;
    previous = Date.now();
    console.log(status, `${gap} ms since the last read`, snapshot.next_poll_after_seconds);
  },
});
console.log(job.status);

Notes

• Reads have their own budget, forty times the write budget on the shipped default, so a 2-second floor on a handful of jobs is nowhere near the limit. See the rate limits table.
• waitForJob resolves for any terminal status; it throws SumeJobTimeoutError (with jobId and lastStatus) when the timeout hits first. The job keeps running, so keep the id and resume.
• For fan-out, a webhook plus a slow poll as backup costs fewer reads than many tight loops.