feat(SDK-520): replace magic 1000ms timeouts with named, configurable…

[jferrao-itrbl]

🔹 JIRA Ticket(s) if any

• SDK-520

✏️ Description

Replace hardcoded magic timeouts:

• Add IterableConfig.androidWakeDelayMs and authCallbackTimeoutMs to expose the two hardcoded timeouts as tunable, documented values.
• Replace the fixed-window auth callback gate with an event-driven Promise latch; the timer survives only as a safety-net fallback.

[github-actions]

Lines	Statements	Branches	Functions
	71.92% (579/805)	61.22% (229/374)	67.18% (174/259)

[qltysh]

⚠️ Comments skipped — @jferrao-itrbl doesn't have a Qlty seat in Iterable.

Qlty doesn't post analysis or coverage comments for contributors without a seat. An authorized user can grant @jferrao-itrbl a seat from this pull request's page in Qlty.

[joaodordio]

Really nice iteration on the latch, the FIFO scoping and the 6s default both look great. One thing I noticed while tracing through the new design that I think is worth catching before this lands:

The FIFO queue only gets drained in the isIterableAuthResponse branch and in the two native listeners. The .catch and the three other .then branches (bare string, null/undefined, unexpected type) push an AuthInvocation but never remove it, so it sits at the head of pendingAuthInvocations as a zombie. Since native emits handleAuthSuccessCalled or handleAuthFailureCalled in all of those paths too (passAlongAuthToken(null) → handleAuthTokenSuccess(null) → handleAuthFailureCalled on Android, semaphore always emits on iOS, and the .catch path hits the 30s native latch timeout which still returns and emits), the zombie ends up catching that event and buffering it into pendingResult where nothing consumes it.

Concrete single-flight trace for the .catch case, which is probably the most common non-happy path in production:

1. handleAuthCalled # 1 fires, inv1 pushed. Queue [inv1].
2. Customer's authHandler throws (network blip, exception in their token fetch, etc). .catch logs. inv1 stays.
3. Native latch times out at 30s, emits handleAuthFailureCalled (Android returns null token → AUTH_TOKEN_NULL; iOS semaphore timeout).
4. Listener finds inv1 at head with no resolver, buffers inv1.pendingResult = FAILURE. onJwtError still fires correctly, all good there.
5. SDK schedules a retry via IterableAuthManager.scheduleAuthTokenRefresh, eventually emits handleAuthCalled # 2.
6. inv2 pushed. Queue [inv1, inv2].
7. authHandler # 2 succeeds with an IterableAuthResponse, latch wired on inv2.
8. Native # 2 succeeds, emits handleAuthSuccessCalled.
9. Listener routes to queue[0] which is still inv1 → buffers SUCCESS on the zombie.
10. inv2's latch never sees it, safety-net wins at 6s, "No callback received" logged, successCallback2 silently dropped.

Also a slow memory leak on the .catch path since every rejected authHandler adds one AuthInvocation for the process lifetime.

The fix I'd suggest is dropping the invocation from the queue in each of those four paths, same shape as the defensive splice you already have in race.then, something like:

const removeInvocation = () => {
  const index = pendingAuthInvocations.indexOf(invocation);
  if (index !== -1) {
    pendingAuthInvocations.splice(index, 1);
  }
};

then call removeInvocation() in the string, null/undefined, unexpected-type branches, and in the .catch. There's a tiny caveat that a late native event for a .catched invocation will then misroute to whatever is at the new head (either nothing, or a newer invocation), but that's a pre-existing bridge limitation with no correlation id and the current behavior is strictly worse since it deterministically blocks the next real callback.

Locking this down with a rejection-then-retry test in the same shape as the great overlap regression test you just added would be perfect, something like: fire handleAuthCalled → reject authHandler → fire handleAuthCalled again → resolve with IterableAuthResponse → assert the second successCallback fires.

[jferrao-itrbl]

Thanks for catching this @joaodordio , really good spot.

Added a removeInvocation() helper scoped to each invocation and called it in all four non-happy paths, dropping the invocation from the queue before native's late event arrives. The no-correlation-id bridge limitation (a late native event for a removed invocation may misroute to the new queue head) is noted in a comment. Strictly better than the zombie-at-head block; full overlap hardening with a correlation id would be a separate bridge-contract change.

Added a regression test: handleAuthCalled → reject authHandler → handleAuthCalled again → resolve with IterableAuthResponse → emit native success → assert the second successCallback fires and no "No callback received" warning is logged.

All tests green and updated rules to make sure similar scenarios are avoided or caught earlier in the future.

[joaodordio]

Thanks for addressing the issues João!

LGTM!