Skip to content

fix: return futures from virtual device and network session APIs - #174

Merged
mortenboye merged 1 commit into
masterfrom
fix/virtual-device-futures
Sep 3, 2026
Merged

fix: return futures from virtual device and network session APIs#174
mortenboye merged 1 commit into
masterfrom
fix/virtual-device-futures

Conversation

@mortenboye

Copy link
Copy Markdown
Contributor

Fixes #173.

Problem

MethodChannelMidiCommand dropped the pigeon call with unawaited, so a platform failure escaped as an unhandled asynchronous error:

PlatformException(AUDIOERROR, Error -2 while create MIDI virtual source, null, null)
  at MidiHostApi.addVirtualDevice (midi_api.g.dart:331)

Wrapping the call in try/catch could not help, because the future was discarded inside the platform implementation rather than returned to the caller.

Fix

addVirtualDevice, removeVirtualDevice and setNetworkSessionEnabled now return Future<void> end to end — MidiCommandMidiCommandPlatformMethodChannelMidiCommand → host API:

try {
  await midi.addVirtualDevice(name: 'My App');
} on PlatformException catch (err) {
  // The virtual source was not created.
}

setNetworkSessionEnabled had the identical unawaited defect one line below the two named in the issue; including it here keeps this to a single breaking-signature change rather than two.

Updated in the same shape: the platform-interface base class, and the web, windows and linux implementations. Web now throws asynchronously via async so its "unsupported" error arrives through the future rather than synchronously.

Compatibility

  • Existing calls that ignore the result keep compiling (midi.addVirtualDevice(name: 'x'); is still a valid statement).
  • Breaking for custom MidiCommandPlatform implementations: the three overrides must widen from void to Future<void>. Documented as migration item 7 in the README.

Verification

  • New test in test/flutter_midi_command_test.dart asserting a platform error reaches a MidiCommand caller, plus a success-path test.
  • New test in the platform interface asserting PlatformException propagates out of MethodChannelMidiCommand.
  • The example app now awaits addVirtualDevice and reverts its virtual transport toggle when creation fails — previously it silently kept the toggle on.
  • flutter analyze clean; root, platform-interface, linux, windows, web (chrome) and example suites pass.

`MethodChannelMidiCommand` discarded the pigeon call for
`addVirtualDevice`, `removeVirtualDevice` and `setNetworkSessionEnabled`
with `unawaited`, so a platform failure such as

    PlatformException(AUDIOERROR, Error -2 while create MIDI virtual source)

escaped as an unhandled asynchronous error. A try/catch around the call
could not see it because the future was dropped inside the platform
implementation.

The three APIs now return `Future<void>` all the way from `MidiCommand`
through `MidiCommandPlatform` to the host API, so callers can await them
and handle failures. Calls that ignore the result keep compiling; custom
platform implementations must widen these overrides from `void`.

The example app now awaits `addVirtualDevice` and reverts its virtual
transport toggle when creation fails.

Fixes #173

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@mortenboye
mortenboye merged commit ef5a5c6 into master Sep 3, 2026
11 checks passed
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.

addVirtualDevice drops its Future, so errors surface as unhandled exceptions

1 participant