fix: complete TypeScript wrapper cleanup

[fadi-george]

Description

One Line Summary

Combine the Capacitor TypeScript wrapper release, demo validation, response handling, tooltip, cache, and lifecycle cleanup.

Details

Motivation

Linear: SDK-5125, SDK-5118, SDK-5122, SDK-5123, SDK-5124.

This consolidates all applicable Capacitor work from the React Native reference audits into one repository branch and PR.

Scope

• Forward target_branch to the shared release preparation workflow while preserving the main default.
• Share in-flight tooltip initialization, cache only successful parsing, and permit later manual retries after non-fatal failures.
• Reject malformed or ambiguous notification success bodies; retry only recognized subscription-indexing failures across all existing demo send paths.
• Reject missing/non-finite outcome values and preserve special dictionary keys such as __proto__.
• Keep the stable demo tarball when packed bytes are unchanged and key each demo install stamp to the tarball hash.
• Guard async demo startup snapshots against newer subscription, permission, and user events.
• Do not port Metro/env cache behavior. Header-title and inline-control remount patterns are absent from these web demos; custom event JSON was already object-only.

References: OneSignal/react-native-onesignal#1981, #1982, #1983, #1984, #1985, #1988.

Testing

• vp test run: 14 files and 224 tests pass; coverage thresholds pass.
• Focused vp check: all 18 changed TypeScript/TSX files pass formatting, lint, and type checking.
• Release workflow formatting and bash -n examples/setup.sh: pass.
• Production web builds pass for demo, demo_pods, demo_cap7, and demo-no-location.
• Shared setup succeeds for both full demos with sync isolated; repeated packing preserves the stable tarball inode/hash when bytes are unchanged, and both per-demo stamps equal the tarball hash.
• Full repository vp check has an unchanged baseline README.md formatting failure; the combined diff does not modify that generated file.

Affected code checklist

• Notifications
• Outcomes
• REST API requests
• Public API changes

Checklist

• I have filled out all required sections
• PR contains the related SDK-5125 cleanup
• No public API changes
• Automated tests pass
• Diff reviewed

  

[sherwinski]

Review of the branch against main. Verdict: ship with small fixes.

The branch adds a tested classifyNotificationResponse helper to all three demos, fixes race conditions in the React useOneSignal hook, deduplicates tooltip initialization, replaces the source-hash tarball cache in examples/setup.sh with a content compare, and forwards target_branch to the shared prep-release workflow.

I checked these points:

• The demo and demo_pods copies are identical.
• The shared prep-release.yml in sdk-shared accepts target_branch.
• vp pm pack writes fixed mtimes and a zero gzip timestamp, so the cmp -s compare in setup.sh works.

The should-fix items are inline. Small items and questions are below.

Small items

• examples/setup.sh:33: if the glob onesignal-capacitor-plugin-*.tgz does not match, the array holds the literal pattern. The script still fails under set -e, but the error from cmp or mv is not clear. A [[ -f "${new_tarball[0]}" ]] check with a message would help.
• examples/setup.sh:27: the script now runs vp run build and vp pm pack on every setup. The old stamp skipped both. The pack step is fast and the tarball compare keeps vp add cached, so this is fine. Please note the tradeoff in the header comment at line 11.
• examples/demo/src/hooks/useOneSignal.ts:246: the handler increments requestSequenceRef, then fetchUserDataFromApi increments it again. The first increment only matters on the null onesignalId path. A short comment would help the next reader.
• Commit 4244d60 says "preserve keys". The Object.fromEntries change has the same behavior as the old loop, so the message overstates the change.

Questions

• Do the new example tests run in CI? The root vite.config.ts includes **/*.test.ts, so a local vp test runs the examples/** tests. No workflow in .github/workflows runs vp test. Is that the plan?
• Can the API return a partial success body for one subscription id? Example: {"id":"x","recipients":1,"errors":{"invalid_player_ids":[...]}}. The classifier returns transient-failure and retries a send that already went out. I expect this cannot happen with a single include_subscription_ids entry, but I could not confirm it.
• A missing id with a recognized error now maps to failure, not transient-failure. The old code treated a missing id as transient. The test for {} shows this is deliberate. Has the v1 endpoint ever returned a recognized indexing error with no id key?

[sherwinski]

Developers who ran the old script still have .capacitor-sdk-source.stamp on disk. After this change, git status shows the file as untracked for them.

Two options:

• Keep this ignore line for a while.
• Add rm -f "$SDK_ROOT/.capacitor-sdk-source.stamp" to examples/setup.sh so the script removes the old stamp.

[sherwinski]

The comment at line 96 still says: "Treat any 200 response with no real id, populated errors, or recipients=0 as transient." The classifier now retries only on recognized subscription-indexing errors. Please update the comment so a later reader does not widen the rule again.

The same comment exists in examples/demo_pods/src/services/OneSignalApiService.ts:96.

[sherwinski]

The comment at line 110 describes the old retry rule. The classifier now retries only on recognized subscription-indexing errors. Please update the comment to match.

[sherwinski]

This check only confirms that the body is an object. A body like {"id":"","errors":["All included players are not subscribed"]} passes, and the user sees no alert. The other demos treat that body as a failure.

At minimum, check for a non-empty id and no errors key. If the no-location demo is intentionally minimal, a short comment that says so is enough.

[onesignal-deploy]

Remaking this PR with a GitHub PAT instead of the Cursor GitHub App.