test(example): de-flake use-rive-trigger #230 (deterministic re-renders)

[mfazekas]

The #230 test drove re-renders with setInterval(50ms) for 300ms and asserted renderCount >= 3 within a 2000ms waitFor. waitFor resolves the instant renderCount hits 3 — i.e. it needs exactly 2 interval ticks, zero margin. When the JS thread is busy at mount (RiveView + dataBind init) the ticks are starved and only 1 lands, so renderCount stays at 2 and the test fails (the intermittent expected 2 to be greater than or equal to 3).

Fix

Drive the re-renders deterministically via an exposed context.rerender() (the pattern issue297.hooks already uses) instead of racing a wall-clock setInterval. The callback-identity churn is preserved; the timing dependence is gone.

Reproduction kept in the test

The PR keeps the failure condition as a permanent regression guard — a 500ms JS-thread block at mount that starves any re-render driver (what RiveView init does on a slow runner). This is the concrete reproduction:

• old setInterval approach + this block → 8/8 fail (renderCount stuck at 2)
• new deterministic approach + this block → 8/8 pass

So every CI run now verifies the fix against the reproduction, rather than relying on the ~1% natural flake. (Locally I also confirmed the natural flake at ~1%, and that renderCount lands at exactly 3 — zero margin — on every passing run.)

CI changes

This PR is not purely a JS test change — it also touches .github/workflows/ci.yml:

• Pin the iOS jobs (build-ios, test-harness-ios) to macos-15 (Xcode 26.3, simulator iPhone 16 Pro on iOS >=26.0). macos-latest is mid-migration to macOS 26, whose simulator set has no matching iPhone 16 Pro / iOS >=26 runtime, which breaks the harness boot ("No devices found"). This overlaps with ci(ios): pin iOS jobs to macos-15 to stabilize simulator boot #300, which pins the same runners; if ci(ios): pin iOS jobs to macos-15 to stabilize simulator boot #300 lands first, this part should be rebased away.
• Add a 300s per-attempt watchdog to the test-harness-ios retry loop. The harness can hang indefinitely if the app launches but never connects to the bridge; without a cap a single stuck attempt eats the whole 15-min step budget and the retry loop never advances. macOS has no timeout, so a background watchdog kills the stuck attempt and nuke_harness reaps the rest before the retry.

[Copilot]

Pull request overview

This PR aims to de-flake the useRiveTrigger harness regression test from #230 by removing wall-clock–driven re-render scheduling and replacing it with deterministic, test-driven re-renders, while also pinning iOS CI runners to stabilize simulator availability.

Changes:

• Add an explicit context.rerender() hook to deterministically churn callback identity in the unstable-callback harness test.
• Keep a mount-time JS-thread blocking reproduction in the test as a permanent regression guard.
• Pin iOS GitHub Actions jobs (build-ios, test-harness-ios) to macos-15 to avoid simulator roulette on macos-latest.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
example/tests/use-rive-trigger.harness.tsx	Replaces interval-based re-rendering with a deterministic context.rerender() driver and retains a mount-time JS-block regression guard.
.github/workflows/ci.yml	Pins iOS jobs to macos-15 to avoid intermittent simulator boot failures tied to macos-latest runner image changes.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.