fix[notask]: wrap job ID counter at MAX_SAFE_INTEGER to prevent precision loss

[sharmaraju352]

Summary

• Add nextSafeId() helper to both whispercpp (whisper.js) and parakeet (parakeet.js) that wraps the job ID counter back to 1 at Number.MAX_SAFE_INTEGER
• Replaces all raw this._nextJobId += 1 increments (3 sites in whisper, 2 in parakeet)

Problem

The _nextJobId counter was incremented without bounds. JavaScript's Number.MAX_SAFE_INTEGER is 2^53 - 1. Beyond this, integer precision is lost and job ID collisions become theoretically possible in long-running server processes (e.g., benchmark servers with cached models).

Solution

function nextSafeId (current) {
  return current >= Number.MAX_SAFE_INTEGER ? 1 : current + 1
}

This preserves Number type compatibility for all existing consumers (no BigInt migration needed) while eliminating the precision loss risk.

How was it tested?

• Whisper unit tests (before & after): 24/24 pass, 90/90 assertions
• Parakeet unit tests (before & after): 11/11 pass, 55/55 assertions
• SDK integration: whispercpp-filesystem.ts example produces identical output
• JS-only change — no native addon rebuild required

Made with Cursor

[github-actions]

Tier-based Approval Status

**PR Tier:** TIER1

**Current Status:** ✅ APPROVED

**Requirements:**
- 1 Team Member approval ✅ (1/1)
- 1 Team Lead OR Management approval ✅ (1/1)



---
*This comment is automatically updated when reviews change.*

[ogad-tether]

LGTM. This is a small, low-risk hardening change, and wrapping at is good enough given the one-active-job-per-instance model.

[ogad-tether]

Clarifying my approval summary: wrapping the counter at Number.MAX_SAFE_INTEGER is a reasonable hardening step here given the one-active-job-per-instance model.

[sharmaraju352]

/review