[rabble]

Closes #6857

What

Slice 1 of 3 of creator sync: a user's saved sound library now mirrors across every device signed into the same Nostr account.

Metadata-only — no blob layer, no server dependency, free for all accounts. Slices 2 (clips) and 3 (drafts) add the media layer and depend on server work tracked separately.

New pure-Dart package mobile/packages/creator_sync:

• Vault key — one random 256-bit key, NIP-44-wrapped to the user's own pubkey and stored as a kind-30078 event. Unwrapped once per device, so bulk crypto never touches the signer (a NIP-46 bunker user would otherwise face one round-trip per synced item).
• Cipher — AES-256-GCM over index payloads under that key.
• Index — one encrypted, addressable kind-30078 event per sound. Replaceable-event semantics supply last-write-wins for free.
• Reconciler — pull, apply, push, with tombstones carrying a NIP-40 expiry.

Plus app-layer adapters, a status cubit, l10n, Riverpod wiring, and the triggers in SavedSoundsBloc / SoundsTab / VideoEventPublisher.

Design decisions worth reviewing

Fails closed on every relay read that gates a write. Both reads use queryEventsDetailed and reject noRelays/timedOut explicitly. queryEvents discards those flags and returns [], so an unreachable relay is indistinguishable from "nothing exists" — in the vault-key lookup that would have generated a second key, replaced the first, and permanently orphaned the user's whole library. The vault-key read also passes useCache: false so "empty" is a statement about the relay, not a local cache hit.

Relay events are untrusted. Kind, pubkey, and an allowlisted d tag are all re-checked before the newest-wins dedup. Without the pubkey check a poisoned event with a newer created_at wins dedup, fails to decrypt, gets skipped — and silently erases a genuine sound while fetch reports success.

d-tag parsing is allowlist-based, not prefix-based. Relay filters can't prefix-match d tags, so this subscription also receives dm_repository's read cursors and this package's own vault-key event. Mis-parsing either would corrupt unrelated state.

Pull commits before push. _local.upsert persists immediately but the cursor was previously committed only after the push loop — so a mid-push relay failure discarded pull progress, and the next pass re-applied the stale relay body over the user's edit. Pinned by a regression test reproducing that exact symptom.

App-shell bloc is re-pointed, not re-keyed. SavedSoundsScope sits above MaterialApp.router; adding the async-resolving repository to its key would remount the whole app seconds into every cold launch (#6477/#6480). Uses identityStreamOf, matching the PeopleListsBloc precedent from #6482.

Crashlytics discipline. Relay, auth, and signer failures are expected here and reach addError unwrapped; only genuine programming errors are Reportable. Pure-Dart package uses the reporter-port typedef.

Testing

creator_sync: 127 tests, 100% coverage (287/287 lines, no coverage:ignore escapes). App layer: adapters, cubit, provider gates, bloc triggers, and widget tests for the sync banner.

Guards are mutation-verified — deleted, watched go red, restored byte-identical. Several tests carry inline comments naming which assertion is load-bearing.

⚠️ The two-device E2E has never been executed

mobile/integration_test/creator_sync/sound_sync_two_device_test.dart is committed but was never run — the Docker daemon was unresponsive in the authoring environment, so local_stack could not start. It is deliberately placed outside integration_test/e2e/ and untagged, so CI analyzes and format-checks it but does not run it.

Do not read it as coverage. Someone with a working Docker should run it once:

cd local_stack && docker compose up -d
cd mobile && flutter test integration_test/creator_sync/sound_sync_two_device_test.dart

Assumptions flagged in the file that are likely to need adjustment on first run: localHost is 10.0.2.2 (Android-emulator-specific; plain flutter test on macOS probably needs localhost), and the vault-key settlement poll interval is an untested guess.

Known follow-ups (not blocking)

• sync_cipher's length guard isn't pinned at the exact 27-vs-28 boundary; an off-by-one would surface an ArgumentError that fetch doesn't catch.
• schemaVersion uses strict equality, so a future v2 client and a v1 client would ping-pong. Zero effect today.
• _canonical sorts keys via toString but indexes with the stringified key — unreachable for JSON-derived bodies, one-line fix.
• package_coverage_floors.txt has a pre-existing sort inversion (image_metadata_stripper before iap_repository) that will cause a spurious re-sort on the next UPDATE_BASELINE=1. Already on main; worth a separate one-liner.

Verification

dart format, flutter analyze lib test integration_test, package_coverage_floor, untested_services_floor, raw_textstyle_ceiling, test_unit_structure, shared_channel_overrides, integration_test_error_restore_safety, and arb_consistency_test all pass — re-run after rebasing onto current origin/main.

🤖 Generated with Claude Code

[rabble]

Review notes (agent review — my own PR, so comment rather than approval)

I read the creator_sync core closely since that's where a bug is expensive. Things I verified rather than took on trust:

• SyncCipher is correct. AesGcm.encrypt without an explicit nonce draws a fresh random 96-bit nonce per call, so there's no reuse hazard; concatenation() is nonce ‖ ct ‖ mac and open reverses it faithfully. The < nonceLength + macLength guard is right at the boundary — a 28-byte box (empty plaintext) is accepted, 27 rejected — so the flagged follow-up is a missing test, not a missing check.
• The fails-closed reasoning holds. Both _fetchRemote and fetch use queryEventsDetailed and reject noRelays/timedOut before interpreting an empty list, and the vault-key read passes useCache: false. This is the right call and matches the queryEvents-hides-relay-failure trap.
• Untrusted-relay handling is thorough in both readers: kind, author pubkey, and an allowlisted d tag are all re-checked before newest-wins dedup.
• Ordering around publish is correct. _generateAndPublish caches the key only after a successful publish, and _obtain decodes-then-caches so a garbage unwrap can't poison the cache permanently. Both are easy to get backwards.
• The unawaited(future.then(onError:)) in-flight cleanup and the comment explaining why whenComplete would leak an unhandled error is subtle and right.

Two things to deal with.

1. The PR has merge conflicts

mergeStateStatus: DIRTY, mergeable: CONFLICTING. The description says the ratchets were re-run after rebasing onto current origin/main, so this has drifted since. Needs git fetch origin && git rebase origin/main and a re-run before it can go in.

2. Two devices on first run can fork the vault key permanently

_inFlight dedups concurrent obtain() calls, and the doc-comment frames that as the protection against two callers "each generat[ing] and publish[ing] a distinct replacement". But that guard is per-process. Nothing covers two devices:

1. Phone and tablet both sign in with a cold VaultKeyCache.
2. Both call _fetchRemote, both get a genuine, relay-confirmed empty result.
3. Both run _generateAndPublish, both publish a kind-30078 at divine:sync:vault-key.
4. Replaceable-event semantics mean one wins on the relays. Both devices cached their own key.
5. The loser never finds out — every later obtain() short-circuits on its cached key, so it keeps sealing items under a key no other device can open, forever.

That's the exact failure the file's own doc warns about ("publishing a second vault key would replace the first and render every previously synced item permanently unreadable") — just reached device-to-device instead of callsite-to-callsite. And installing on a second device is a completely ordinary thing to do the same evening you install on the first, which is precisely when both caches are cold.

_generateAndPublish never reads back after publishing. The fix is to re-fetch after a successful publish and adopt whichever event the relays actually converged on, caching that rather than the locally generated key. The E2E already gestures at needing this — it carries a "vault-key settlement poll interval" — but the settlement wait lives in the test, not in the service.

Given the whole design rests on the vault key being singular per account, I don't think this should ship without a read-back.

3. Newest-wins has no tie-break (makes #2 worse)

Both readers resolve "newest" by createdAt alone:

// vault_key_service.dart
..sort((a, b) => b.createdAt.compareTo(a.createdAt));
// sync_index_client.dart
if (existing == null || event.createdAt > existing.createdAt) { ... }

On equal createdAt the winner is whichever order the relay happened to return, so two devices given the same two events can pick different ones and stay disagreeing. NIP-01 breaks replaceable-event ties by lowest event id. Two devices publishing within the same second is exactly the #2 scenario, so adding the tie-break here removes the nondeterminism even before the read-back lands.

Smaller

• fetch queries every kind-30078 for the author — no d filter, since item tags are per-item and can't be enumerated. Correctness is fine (the allowlist catches DM cursors and the vault-key event), but the payload grows with the user's entire app-specific-data footprint across every app they use, and it's re-fetched on each reconcile. since mitigates it after the first pass. Worth a comment noting the cost is accepted, since it looks like an oversight otherwise.
• The listed follow-ups are the right calls. Worth confirming the schemaVersion strict-equality ping-pong really is inert today rather than merely unreachable-in-practice — a v2 client shipping later turns it live, and a ping-pong between two clients is the kind of thing that only shows up as relay-write amplification.

On the unrun E2E

Flagging it this loudly is the right thing to have done, and placing it outside integration_test/e2e/ untagged so CI analyzes but doesn't run it is the correct compromise. It does mean the two-device path — which is where #2 lives — has no executed coverage at all. If someone runs it before merge, the first thing worth doing is starting both simulated devices with cold caches simultaneously, since that's the case the current code doesn't handle.

Everything else in here is careful work; the crypto and the fail-closed discipline in particular are well above the bar. It's the multi-device key establishment that needs another pass.

[realmeylisdev]

ran this on iOS against relay.divine.video, and got your two-device E2E running against local_stack. three things I think need fixing before it ships, details inline: publishEvent never reads the relay's OK, so a rejected publish gets recorded as applied and never retried. the vault key lookup reads "relay hasn't flushed the write yet" as "no key exists" and mints a second key over the first. and the new delete-retry loop treats an unreadable local library as an empty one, which tombstones the whole library.

rest are nits. fwiw the guards you say are pinned really are, I mutated five of them and they all went red.

[realmeylisdev]

blocking. publishEvent reports success as soon as the frame is written to a socket, not when the relay accepts the event. RelayPool._sendCollect says it outright:

An entry in the returned list means the relay's WebSocket accepted the frame (or it was queued for pending-auth delivery). It does NOT mean the relay accepted the event at the protocol level, use sendEventAwaitOk for that guarantee.

Nostr.sendEvent returns the event whenever _pool.send is true, and publishEvent maps that to PublishSuccess. So every OK false reads as success here, and the caller records applied[dTag] = (stamped, hash). That is exactly the state that makes reconcile()'s push loop skip the item forever, so the retry this PR is built around never fires.

Rejections that reach this path today: a NIP-86 disallowkind, created_at more than 60s ahead (relay.rs:1340, max_created_at_drift_seconds, which SyncClock can produce from a fast clock or from clamping to latestKnownRemote + 1), content over 100KB, and rate limiting.

Tombstones are worse. publishLocalDeletion records tombstoneHash, and the delete-retry loop skips tombstoneHash entries by design, so a rejected deletion is never retried and the sound stays alive on every other device.

Measured: three creator-sync shaped kind-30078 events sent to local_stack came back ["OK",<id>,false,"blocked: kind 30078 not in allowed list"] and a readback returned zero events. That exchange is PublishSuccess on this code path.

publishEventAwaitOk gated on acceptedByAny is the fix. Your own harness already knows this one: sync_e2e_harness.dart:100 polls until the vault key is queryable, with the comment "publishEvent, which does not await relay OK".

[realmeylisdev]

Fixed in a2f3b53. Publish goes through publishEventAwaitOk gated on acceptedByAny, so an OK false no longer gets recorded as applied. Test pins the every-relay-rejects case and goes red without the guard.

[realmeylisdev]

blocking. The fail-closed handling above covers noRelays and timedOut, but not the case that actually happens: a relay that answers promptly and honestly with nothing because it has not committed the write yet. Relay::query goes straight to storage.query_events_with_limit with no in-flight batch overlay, and production runs BATCH_INTERVAL_MS=180000 (divine-iac-coreconfig funnelcake-relay deployment.yaml:80).

Returning null here sends obtain() into _generateAndPublish, which is the outcome the doc comment above says must never happen. Same d tag, so the second key replaces the first. Device A keeps its cached key forever since obtain() short-circuits on the cache and never rechecks, and from then on every record either device publishes is undecryptable to the other. fetch swallows that as "skipping undecryptable sync record", so both devices sit at "Sounds up to date" with nothing syncing, permanently, and no recovery path.

This is not gated on opening the Sounds tab. main.dart reads soundSyncRepositoryStreamProvider, identityStreamOf uses container.listen, so obtain() runs at cold start. On my iOS run the vault key event's created_at lands at app launch, about two minutes before I first opened the tab. A second device only has to be launched inside the window.

Repro is in your own E2E: a sound saved on device A appears on device B fails Expected: <1> Actual: <0> as written, and passes with 8s inserted between the two reconciles.

[realmeylisdev]

Already fixed in a87b936 before this landed — _adoptSettled reads the key back off the relays and adopts whichever one they retained, caching nothing until then. Same fix shape, arrived at independently. Nothing further from me.

[realmeylisdev]

blocking. This infers "the user deleted this sound" from "it is not in readAll()", but SavedSoundsService.loadSavedSounds() returns [] for at least three reasons that are not a deletion:

• jsonDecode throws, swallowed by the outer catch (_) (saved_sounds_service.dart:74)
• the payload was written by a newer build, _isNewerSchema returns [] (:146)
• the key is absent

Any one of them makes every entry in applied look locally deleted in a single pass, so this loop publishes a tombstone for the whole library and the user's other devices apply them as genuine deletions via _local.remove.

The newer-build case is the pointed one. _writeSavedSounds deliberately throws Refusing to overwrite a saved sound library written by a newer build so a v1 client cannot flatten a v2 library locally. This loop routes around that protection by deleting it remotely instead.

Worth having LocalSoundStore.readAll() distinguish "empty" from "could not read", or at minimum skipping the retry pass when localSounds is empty and applied is not. Leaving the shape to you since it changes the port contract.

[realmeylisdev]

Fixed in 0514ae5. SavedSoundsService gained isLibraryUnreadable, the adapter throws LocalStoreUnreadableException instead of reporting an empty library, and LocalSoundStore.readAll documents the contract. Tests cover corrupt JSON, a newer-build payload and a versioned map with no sound list, plus the two readable-but-empty shapes that must still tombstone normally.

[realmeylisdev]

should-fix, and probably your call since it is a wire-format decision. The body is encrypted, the d tag is not, and it carries the full sound id. Anyone can send REQ {"kinds":[30078],"authors":["<pubkey>"]} unauthenticated and read back exactly which sounds an account saved, how many, and when from created_at. I confirmed the unauthenticated read works against relay.divine.video (it returned the divine:sync:vault-key event for my own pubkey).

For a feature whose premise is an encrypted index that is a real leak, and it widens in slices 2 and 3 when clip and draft ids go the same way. An HMAC of the id under the vault key would keep addressability and replaceability while making the tag opaque.

[realmeylisdev]

Left for you, as flagged — the remedy is a wire-format change with a migration cost for anything already published, which is your call rather than something to push into the branch.

[realmeylisdev]

nit, the code is right but the reason given is not. dm_repository's read cursors can never reach this subscription: publishSelfApplicationMarker builds the kind-30078 marker as a rumor and publishes it inside a NIP-59 gift wrap (nip17_message_service.dart:756, dm_repository.dart:1807), so on the relay it is a kind-1059 event and Filter(kinds: [30078]) cannot return it. Allowlist parsing is still correct and still needed, just for the vault-key event, which is a real bare 30078 sharing the prefix. Same claim is in the PR description.

[realmeylisdev]

Fixed in 7488aa9, comment only. Both sites now name the vault-key event and other apps' app-specific data instead of DM read cursors, which cannot reach a kind-30078 filter.

[realmeylisdev]

should-fix. close() calls super.close() first, which closes _eventController synchronously, and only cancels this subscription a microtask later. Anything the stream delivers in that window hits add() on a closed bloc. In bloc 9.2.1 add() calls _eventController.add, which throws StateError, passes it to onError, and then rethrows. A throw out of an onData handler goes to the zone's uncaught handler rather than this subscription's onError, so it surfaces through main.dart's runZonedGuarded.

Account switch is where both sides fire together: the provider re-resolves and re-emits while SavedSoundsScope re-keys and closes the old bloc. _probe() a few methods down already guards with if (!isClosed), the same guard works here.

[realmeylisdev]

Withdrawn — I could not reproduce it. close() awaits the subscription cancel immediately after super.close() flips isClosed, and the cancel drops queued deliveries before the listener runs. Probed a single-subscription controller, a sync broadcast controller, and the Stream.multi-over-broadcast shape identityStreamOf actually builds, including closing right after construction so the seed was still in flight: the listener never once ran with isClosed true. The code is fine as written.

[realmeylisdev]

should-fix. The local delete already succeeded above, but the completer and the emit that actually removes the row both wait on this relay round trip. RelayPool.perRelaySendTimeout is 5s per relay and the fan-out is sequential, and publishEvent calls retryDisconnectedRelays() first when the pool is empty, so on a degraded network the deleted sound stays on screen and the caller's future stays pending for seconds. _save has the same shape, the save callback waits on the publish before it resolves.

_mirror swallows everything, so this can never fail the operation. For work its own doc calls best-effort it should run after the emit, not in front of it.

[realmeylisdev]

Fixed in 4b61220. Both paths complete the completer and emit off the local write, then mirror. Two tests hold a publish open and assert the save/removal has already landed.

[realmeylisdev]

nit, but it means the run instructions in the test header do not work as written. localHost is 10.0.2.2, the Android emulator host alias, so flutter test integration_test/creator_sync/... on macOS never reaches local_stack.

Two more things I hit getting it to run, so nobody has to rediscover them. local_stack's relay image predates the 30000-39999 auto-allow in relay.rs:1506, so it answers every kind-30078 publish with blocked: kind 30078 not in allowed list. Unblock with INSERT INTO nostr.allowed_kinds (kind) SELECT 30078 WHERE 30078 NOT IN (SELECT kind FROM nostr.allowed_kinds) and restart local_stack-funnelcake-relay-1.

With the host pointed at 127.0.0.1 and the kind allowed, the suite runs: 2 pass, 2 fail. The failures are the propagation issue in my vault_key_service comment. Also note a deletion on A removes the sound on B and stays deleted currently passes vacuously, B never received the sound so readAll() is empty either way.

[realmeylisdev]

Fixed in c1cef2b, header comment only — it now says the documented command reaches local_stack only from an Android emulator, and why (localHost is hardcoded to the emulator-only 10.0.2.2 alias).

[realmeylisdev]

nit. These four are user-visible banner copy, so they are better translated into the 16 locales than parked in the debt list. hm21 pushed back on exactly this for new strings on #5168.

[realmeylisdev]

Fixed in 39fca60. All four keys translated into the 21 non-English locales and removed from _knownUntranslatedDebt; lib/l10n/generated regenerated and the consistency test passes.

[rabble]

Rebased onto d31fd9d69 and pushed. Conflicts are resolved, both design findings are fixed, and the branch now sits directly on current main (DIRTY cleared).

Rebase — 29 commits, three conflicts

1. arb_consistency_test.dart — purely additive both sides. Union: kept main's videoMetadataC2paMissingNoteServiceUnavailable and its new _profileBadgeFooterKeys block verbatim, added the four soundSyncStatus* keys alongside the other sound-library keys.
2. video_providers.dart (twice) — this one needed a decision rather than a side-pick. fix(sounds): unblock legacy sound reuse and stop the blocked-tap toast queue #6772 on main removed the soundsRepository parameter from AudioReuseConsentResolver; git took that deletion cleanly, which left this branch's consentSoundsRepository with no consumer at all — its only use was that parameter, and the matching ref.onDispose went with it. Resolved by keeping soundSyncRepository and dropping consentSoundsRepository entirely. Verified no dangling references remain.
3. video_providers.g.dart — riverpod source hash. Neither side's was right once the provider body changed, so it was regenerated (283c4ff84, one line).

dart format run explicitly over all three afterwards, since rebase resolutions bypass the local format hook.

Vault-key fork — confirmed, fixed in a87b936b1

No mitigation existed anywhere. Worth noting the branch already knew: sync_e2e_harness.dart:100-104 polls _waitForVaultKeyEvent before device B calls obtain(), commented "otherwise B would see 'no remote key' and mint a second one, permanently orphaning device A's." The guarantee lived in the test harness, not the service.

There's also a narrower single-device variant: publishEvent returns success once the pool accepted the frame, not once a relay stored it — so the cached key could correspond to an event that never landed, and the next device would legitimately find nothing and mint over it. Same permanent outcome, no race needed.

_generateAndPublish now ends in _adoptSettled, which re-reads the vault-key event and adopts whichever one the relays retained. New invariant: nothing is cached until a relay has served it back.

Two judgement calls, both reversible one-liners:

• Settle budget 20 × 250ms = 5s, taken from the numbers the E2E harness already found sufficient against local_stack rather than invented. The delay is injected (settleDelay ctor param) so tests drive the loop with no real waits — no bare Future.delayed in the logic.
• Fail-closed on read-back failure — empty, unreachable, or unwrappable throws and caches nothing. Safe precisely because nothing was cached: no item was sealed under the discarded key. It lands on the existing SoundSyncVaultLocked banner. Cost: soundSyncAvailabilityProvider is a FutureProvider resolving once per session, so a transient read-back miss leaves sync off until the provider rebuilds. Rare-and-recoverable over rare-and-permanent, but reversible if you'd rather trade differently.

Honest limit: the read-back narrows the race, it doesn't close it to zero. If device B publishes after A's window has closed they can still diverge. What makes 5s adequate is that the fork already requires both devices to fetch-empty within relay-propagation time of each other.

NIP-01 tie-break — 57e492626

One shared helper (replaceable_event_order.dart) so the rule has a single definition, wired into both _fetchRemote's sort and fetch's per-d-tag dedup. Both tests assert the same answer for both relay orderings and were mutation-tested against the old createdAt-only comparison.

Correction to my earlier note on since

I said since was doing incremental work after the first pass. It isn't — it has no production caller. SoundSyncRepository.reconcile() calls _index.fetch(SyncItemKind.sound) with no since; the parameter is exercised only by sync_index_client_test.dart:377. So every reconcile is a full unbounded fetch of the account's entire kind-30078 corpus. fetch also doesn't pass useCache: false, unlike _fetchRemote, so it pulls local event-DB accumulation too.

Left unchanged, because wiring it isn't trivial: the obvious since = max(applied.createdAt) interacts badly with SyncClock's skew clamping — a peer device whose created_at was clamped below this cutoff would be skipped forever. That hazard deserves recording before anyone implements it.

Verification

creator_sync 137 tests pass, 320/320 lines = 100.00% (was 287/287; no coverage:ignore added). flutter analyze lib test integration_test clean. All ratchets pass except check_ios_extension_signing_contract and check_native_transport_security, which fail identically on main — environment-dependent, not from this branch.

The two-device E2E still has not been run (no Docker here). Its _waitForVaultKeyEvent poll is now redundant with the service-side settlement, but I left it in rather than delete code I can't execute.

[realmeylisdev]

Pushed six commits, one per finding, all checks green. Revert any of them freely.

• a2f3b53 — publish via publishEventAwaitOk gated on acceptedByAny, so a relay's OK false stops being recorded as applied and silently never retried.
• 0514ae5 — readAll() fails closed on a saved-sound payload it cannot decode, instead of reporting an empty library that the delete-retry pass then tombstones account-wide.
• 4b61220 — _save/_remove complete and emit off the local write, then mirror. _edit already had this shape.
• 7488aa9, c1cef2b — comment corrections (the kind-30078 allowlist, and why the E2E run command needs an emulator).
• 39fca60 — the four soundSyncStatus* keys translated into all 21 locales, out of the debt list.

Two things worth reading rather than taking from the list.

I withdrew one finding. My note on saved_sounds_bloc.dart:42 — add() reaching a closed bloc from the stream listener — does not reproduce. close() awaits the subscription cancel immediately after super.close() flips isClosed, and that cancel drops queued deliveries before the listener runs. I probed a single-subscription controller, a sync broadcast controller, and the Stream.multi-over-broadcast shape identityStreamOf actually builds, closing right after construction so the seed was still in flight. The listener never ran with isClosed true. No guard needed; the code is right as written.

One is still yours: the plaintext d tag. Changing it is a wire-format decision with a migration cost for anything already published, so it stays with you.

Your vault-key fix landed before my review did, and it's the right shape — _adoptSettled caching nothing until the relays serve the key back closes the fork I was worried about, and the NIP-01 tie-break removes the ordering nondeterminism underneath it. I read both closely rather than assuming.

Verification: creator_sync 141 tests, 325/325 lines; flutter analyze lib test integration_test clean; the sound, sync, library-widget and l10n suites pass locally. Each new guard was checked by breaking it first — the publish-acceptance check, the unreadable-library check and both mirror-ordering pins all go red when reverted.

One note on CI while you're reading shard results: Tests (shard 0/4) failed twice on this branch before these commits, on ClipThumbnailImage renders a custom placeholder for a missing file and once also on an UploadManager count assertion. Both pass standalone and both cleared on a re-run with a fresh ordering seed — CI runs --test-randomize-ordering-seed random, so these are merged-isolate pollution surfacing seed by seed. The ClipThumbnailImage one also failed on main's own latest run, so it isn't from this branch either way.

[github-actions]

Mobile PR Preview

Preview refreshed for b30b702

Last refresh: b30b702 at 2026-08-10 04:44:15 UTC (preview run)

Property	Value
Preview URL	https://5ea3ee50.openvine-app.pages.dev
Pages project	openvine-app
Preview branch	pr-6856
PR branch	feat/creator-sync-sounds
Commit	b30b702