Error: Expected a value of type 'FutureOr<JSObject<CryptoKey>>?', but got one of type 'CryptoKey'

[CDDelta]

The JS interop in this package breaks on the latest Flutter dev build which just enabled unsound null-safety enabled by default.

This issue seems to be isolated to dartdevc as production builds work and doesn't happen on older versions of Flutter/Dart SDK. I'm assuming enabling unsound null-safety should not break existing code right?

This issue can be reproduced by generating a new Flutter web application with the latest dev build, installing the package above, replacing main.dart with the below:

import 'dart:convert';
import 'package:cryptography/cryptography.dart';

void main() async {
  hkdf.deriveKey(
    SecretKey.randomBytes(256),
    info: utf8.encode('123'),
    outputLength: 256,
  );
}

and running it on Chrome through flutter run in debug mode.

In the meantime, is there a way to disable null-safety behaviour in Flutter? Adding // @dart=2.9 to main.dart doesn't seem to disable unsound null-safety. Is that intentional?

Flutter: 1.26.0-1.0.pre
Dart: 2.12.0-141.0.dev
OS: MacOS Big Sur

Full output:

Launching lib/main.dart on Chrome in debug mode...
lib/main.dart:1
Debug service listening on ws://127.0.0.1:64418/5GhTnQuSyFk=/ws
Running with unsound null safety
For more information see https://dart.dev/null-safety/unsound-null-safety
Connecting to VM Service at ws://127.0.0.1:64418/5GhTnQuSyFk=/ws
Error: Expected a value of type 'FutureOr<JSObject<CryptoKey>>?', but got one of type 'CryptoKey'
    at Object.throw_ [as throw] (http://localhost:64376/dart_sdk.js:5287:11)
    at Object.castError (http://localhost:64376/dart_sdk.js:5258:15)
    at Object.cast [as as] (http://localhost:64376/dart_sdk.js:5574:17)
    at dart.NullableType.new.as (http://localhost:64376/dart_sdk.js:7122:60)
    at http://localhost:64376/dart_sdk.js:60635:139

I'm getting the same error after upgrading my pods and it completely breaks my app... Does it get fixed if I upgrade to cryptography 2.0.0-nullsafety.2?

[sigmundch]

I believe this is now obsolete, but to confirm:

@nshahan - initially I thought this may be related to #45870, but looking more closely at the workaround submitted in the cryptography package dint-dev/cryptography#36, this is looking more like an issue in how js-interop was wired up by the package. (especially seeing the other native error in dint-dev/cryptography#28 (comment))

Given that, I feel like the recent changes from @srujzs to complain about using @JS on native types would have likely detected this problem, and the in-progress changes to allow static interop types would have allowed for a more incremental solution to that problem.

[nshahan]

I agree that this issue is probably obsolete now, but if it's not I'd really like to know about it.