Skip to content

fix(web): swallow non-UpdateNotification BroadcastUpdates payloads#143

Open
wojciechlas wants to merge 1 commit into
powersync-ja:mainfrom
wojciechlas:fix/broadcast-updates-cast-uncaught
Open

fix(web): swallow non-UpdateNotification BroadcastUpdates payloads#143
wojciechlas wants to merge 1 commit into
powersync-ja:mainfrom
wojciechlas:fix/broadcast-updates-cast-uncaught

Conversation

@wojciechlas
Copy link
Copy Markdown

Summary

On Flutter web, a cross-tab BroadcastChannel message that does not deserialise into an UpdateNotification surfaces as an uncaught DartError:

TypeError: Instance of 'LegacyJavaScriptObject':
  type 'LegacyJavaScriptObject' is not a subtype of type 'UpdateNotification?'

Two surgical changes fix it:

  1. lib/src/web/database/broadcast_updates.dart — make the cast type argument explicit (.cast<UpdateNotification>()) so type inference matches the declared Stream<UpdateNotification> return type rather than inferring the nullable source-stream element type.
  2. lib/src/web/database/async_web_database.dart — attach an onError handler on the broadcast subscription so any residual malformed peer payload degrades silently instead of escalating to an uncaught error on the root zone.

Root cause

BroadcastUpdates.get updates chains .map(...) → .where(...) → .cast(). After .where() removes nulls, the source element type is still UpdateNotification?. A bare .cast() lets DDC infer the cast target from the source element type (UpdateNotification?) rather than from the declared Stream<UpdateNotification> return type. When a peer publishes a payload that survives .where() but isn't an UpdateNotification (legacy storage mode, SharedWorker fallback, or otherwise non-conforming BroadcastChannel data), the cast throws.

Because the downstream .listen() in async_web_database.dart has no onError handler, the cast failure escalates to an uncaught error on the root zone. On Flutter web this surfaces as a DartError popup; a host app using PlatformDispatcher.onError also sees it.

dart2js production builds may mask the symptom thanks to stricter type inference at compile time, but DDC users hit it on every reproducer.

Reproducer

Open two tabs of any Flutter web app using sqlite_async with shared-tab broadcast updates. Trigger a write in one tab that fires broadcastUpdates.send(...). The second tab logs the cast error and (on DDC) raises an uncaught DartError popup.

Changes

  • lib/src/web/database/broadcast_updates.dart: .cast().cast<UpdateNotification>()
  • lib/src/web/database/async_web_database.dart: add onError handler on broadcastUpdates.updates.listen
  • pubspec.yaml: bump to 0.14.2-wip
  • CHANGELOG.md: entry under 0.14.2-wip

Test plan

  • Existing test suite unaffected (no behavioural change for valid payloads).
  • Manually verified two-tab repro no longer raises an uncaught error on Flutter web (DDC).

Happy to add a regression test if you can point me at the right web test fixture layout.

Notes for maintainers

  • Both patches are upstream-quality (defensive type tightening + missing onError); no API surface change.
  • Suggest semver patch bump.

🤖 Generated with Claude Code

`BroadcastUpdates.get updates` chains `.map(...) → .where(...) → .cast()`.
After `.where()` removes nulls, the source element type is still
`UpdateNotification?`, and a bare `.cast()` lets DDC infer the cast target
from the source rather than the declared `Stream<UpdateNotification>`
return type. A peer message that survives `.where()` but isn't an
`UpdateNotification` (legacy storage mode, SharedWorker fallback,
non-conforming `BroadcastChannel` payload) then throws.

Because the downstream `.listen()` in `async_web_database.dart` has no
`onError` handler, the cast failure escalates to an uncaught error on the
root zone. On Flutter web this surfaces as a `DartError` popup.

Two surgical changes:

- `broadcast_updates.dart`: make the cast type argument explicit
  (`.cast<UpdateNotification>()`) so type inference matches the declared
  return type.
- `async_web_database.dart`: attach an `onError` handler on the broadcast
  subscription so any malformed peer payload degrades silently instead of
  crashing the host application.

No API surface change. Bumped to `0.14.2-wip` per DEVELOPING.md.
Copilot AI review requested due to automatic review settings May 13, 2026 08:48
Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Fixes an uncaught Flutter web (DDC) error when cross-tab BroadcastChannel traffic contains payloads that don’t deserialize into UpdateNotification, ensuring malformed peer messages don’t crash the host app.

Changes:

  • Make the stream cast in BroadcastUpdates.updates explicit (cast<UpdateNotification>()) to align type inference with the declared Stream<UpdateNotification>.
  • Add an onError handler to the broadcast-updates subscription in AsyncWebDatabaseImpl to prevent uncaught root-zone errors from malformed messages.
  • Bump package version to 0.14.2-wip and add a changelog entry describing the web fix.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File Description
packages/sqlite_async/lib/src/web/database/broadcast_updates.dart Makes the post-where() cast explicit to avoid incorrect inference and runtime cast failures surfacing uncaught.
packages/sqlite_async/lib/src/web/database/async_web_database.dart Adds an onError handler on cross-tab update listening to avoid uncaught errors on malformed payloads.
packages/sqlite_async/pubspec.yaml Bumps package version to 0.14.2-wip.
packages/sqlite_async/CHANGELOG.md Documents the web broadcast update error-handling fix under 0.14.2-wip.

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

Comment on lines +76 to +78
// malformed peer messages, SharedWorker fallback). Drop them
// rather than crashing the host application via an uncaught
// error on the root zone.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants