Update to Dart 2.5.0

[domesticmouse]

No description provided.

[domesticmouse]

I'm seeing the following error when I attempt to direct traffic to the Dart 2.5 backend:

Error compiling to JavaScript:
Failed to decode request with internal error: type 'Utf8Decoder' is not a subtype of type 'StreamTransformer<Uint8List, String>' of 'streamTransformer'

Something has changed. No idea what.

/cc @devoncarew @johnpryan @RedBrogdon

[devoncarew]

Do you have a stacktrace?

[devoncarew]

We may be hitting some aspect of dart-lang/sdk#36900.

[domesticmouse]

I’m currently in transit, but the Dart 2.5 dart-services version is still provisioned on gae, just not receiving traffic.

[domesticmouse]

I've spent several hours attempting to replicate this issue. Turns out, dart-services works fine locally, it works fine inside of a docker container when I change the serving endpoint to bin/server_dev.dart on both my mac laptop and on a GCE hosted debian drawfork docker host. I even rebuilt the GAE Flex image, but no.

[devoncarew]

Hmm, perhaps you're using slightly different package versions than the remote instance? You could try running pub upgrade to see if you hit the issue; or, delete the pubspec.lock file entry from the gitignore file, commit the lock file, re-deploy, and see if the problem is solved.

[tvolkert]

Yeah, if your remote container is tied to an older package, it may not have picked up a fix for dart-lang/sdk#36900

[RedBrogdon]

I've started looking into this, since Brett's on Australian time and dealing with an OOO situation on top of it.

[RedBrogdon]

Underlying cause is a break in the rpc package. I've created a fix here, but have no idea how to land it:

dart-archive/rpc#140

[tvolkert]

Is it worrisome that we're depending in something in dart-archive?

[domesticmouse]

I tried to land an update to RPC a while back, but Mit said no. I had been moving in the direction of migrating from RPC to gRPC, but other things got in the way. I'd say the best way at this point is to vendor RPC into dart-services and dart-pad. We obviously need to migrate off of rpc.

/cc @mit-mit

[RedBrogdon]

Is it worrisome that we're depending in something in dart-archive?

Yes.

There are trade-offs being made here in terms of infrastructure updates vs. new feature development, though. We need to move away from the discoveryapis/rpc setup currently in use, but unforking flutter_web in the backend and getting the new playground done have so far taken precedence.

@domesticmouse Pulling rpc into the repos is an option, but it's also (at least at little) more work for what is essentially a patch job we want to replace anyway (be it with gRPC or OpenAPI). If we can make this one update to get back on track, that's likely to be a quicker way to get where we're going.

[domesticmouse]

OpenAPI is not a replacement for RPC, it is a way describing the API exposed by RPC. gRPC likewise is not a clean replacement for RPC as it is less expressive and the web browser usage is still in development. In short, the current approach is hard deprecated, the new approach is still in development.

[mit-mit]

grpc-web is supported as of a few weeks ago

[domesticmouse]

Sounds like the best approach is to vendor in rpc while we migrate to grpc-web