fix: [SDK-4754] guard IndexedDB reads + writes from iOS Safari PWA wedge

[sherwinski]

Description

1 Line Summary

Extend the iOS Safari PWA IndexedDB wedge guard to cover reads as well as writes, so OneSignal.init() no longer re-hangs ~30 min after a push subscription on subsequent navigations.

Details

Background: the 160605 fix (#1468) capped writes to the Options store with a timeout + page-scoped circuit breaker. On-device verification showed the WebKit readwrite wedge is DB-wide, not Options-specific, so this branch first generalized the guard to every readwrite op (put/delete/clear) across all stores.

That still wasn't enough. The key insight, confirmed with on-device breadcrumb logging:

• Our timeout makes the JS promise resolve, but the underlying IndexedDB readwrite transaction stays open. WebKit then serializes every later op queued behind it on that object store — including reads.
• So guarding writes alone let init() clear the wedged Options write, advance past internalInit / sessionInit, then hang on the first post-wedge read of the same store — getSubscription's Options reads inside storeInitialValues. Reads on other stores (Ids/*) completed fine, which is why the hang looked like it moved.

This change routes get/getAll through the same timeout + circuit breaker as the writes:

• Refactors guardReadwrite → a generic guard(label, op, fallback); renames readwriteWedged → dbWedged, READWRITE_TIMEOUT_MS → DB_TIMEOUT_MS. isReadwriteWedged() is kept as the exported getter (consumed by initSaveState's app-ID-deferral bail-out).
• Once the breaker trips, every op short-circuits for the page's lifetime: writes → no-op, get → undefined, getAll → []. A read that itself stalls also trips the breaker.
• Dropped writes are session metadata the SW re-derives, or idempotent queued operations retried on the next clean load. Dropped reads fall back to the in-memory model state hydrated before the wedge.

The preview/pageA.html repro now calls login + addTag after init so the operations store keeps getting writes on every load — this mirrors the customer's app and reliably triggers the wedge + same-store read hang. (Kept in this PR to make the fix verifiable; can be reverted before/after merge.)

Systems Affected

• WebSDK
• Backend
• Dashboard

Validation

Tests

Info

• vp check: 0 errors.
• vp test --run: 519 passed. The breaker regression test now asserts that after a wedged write trips the breaker, reads short-circuit too (get → undefined, getAll → []), not just writes.
• vp run build:prod: clean, size-limit within budget, API validation passed.

Confirmed on device (iOS Safari PWA, clean slate per run): delete ONE_SIGNAL_SDK_DB / reinstall PWA → Page A → Page B → Register → B → A. The breaker trips once (db.put(...) timed out warning), all subsequent ops short-circuit, and init() completes in ~1.6s instead of hanging ~30 min.

Checklist

• All the automated tests pass or I explained why that is not possible
• I have personally tested this on my machine or explained why that is not possible
• I have included test coverage for these changes or explained why they are not needed

Screenshots

Checklist

• I have included screenshots/recordings of the intended results or explained why they are not needed (log-based diagnosis; behavior covered by unit tests + on-device steps above)

---

Related Tickets

• SDK-4754 (this fix)
• Follow-up to SDK-4336 / [Bug]: OneSignal.init() hangs on subsequent page navigations in iOS Safari PWA after push subscription is registered #1452 / release 160605 (fix: [SDK-4336] guard IndexedDB Options writes from iOS Safari PWA wedge #1468)
• WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=315804

---

[fadi-george]

Changes seem fine, double check nothing breaks from this "wedge" logic

[sherwinski]

A few things worth knowing when reviewing:

1. Why reads needed guarding too
The earlier write-only guard was correct for a minimal reproduction but init still hung. Our timeout resolves the JS promise, but the underlying WebKit readwrite transaction stays open, and on iOS the persistent (SQLite) IndexedDB backing store runs only one transaction at a time for the whole database — not one per object store. So once a write wedges, every later op queued behind it is blocked DB-wide, reads included, and WebKit has no server-side timeout to abort it (the ~30 min "recovery" is actually iOS terminating the suspended process, which finally closes the connection). That's why guarding get/getAll, not just writes, is what fully unblocks init(): at the engine level there's a single global lock, so once it's stuck nothing else can run until the page is gone. (Cases where reads of other stores seemed to succeed were reads that completed before the wedge, not concurrent with it.) Verified against the iOS 18.1 WebKit source; tracked upstream at https://bugs.webkit.org/show_bug.cgi?id=315804.

2. It's possible that a benign update-subscription 400 (result = 3) can occur.
result = 3 is ExecutionResult._FailNoretry, so that specific stale/batched op is dropped, not retried. The push token still converges: it's re-derived from the browser pushManager on every load, and a fresh update-subscription op is enqueued reflecting the correct state. Even if that op's persistence is short-circuited during a wedged load, it's re-enqueued and flushed on the next clean load. In my experience, this only occurs in situations when you navigate away during the original op, interrupting the process.