cupertino_http web socket tests failing with flutter 3.3.5

[brianquinlan]

DefaultSessionConfiguration local close with code and reason (failed)
  Expected: <3000>
    Actual: <1006>

The reason is that the client seems to not send the close code and reason.

[brianquinlan]

It looks like the only close is being sent by the server (port 49241) to the client (port 49242)

[brianquinlan]

It looks like the socket is just being closed on the client side i.e. it is sending FIN ACK

[brianquinlan]

I changed one of the tests to look like this:

      channel
        ..sendText('Hello World')
        ..sendText('Hello World 2')
        ..sendText('Hello World 3');
      await Future<void>.delayed(const Duration(seconds: 5));
      await channel.close(3000, 'Client initiated closure');

Looking at the timing of the TCP dump, it looks like cancelWithCloseCode is just terminating the TCP connection instead of sending a WebSocket close frame.

[brianquinlan]

Bisecting flutter, it looks like this is the culprit PR: flutter/flutter@9d3d0dc

[brianquinlan]

@liamappelbe Do you have any state on how flutter/flutter@9d3d0dc could affect FFI calls? Or do you think it is unrelated?

[liamappelbe]

I don't see any reason why thread merging would affect FFI calls, other than obviously the calls are coming from the platform thread now. Maybe the API you're talking to behaves differently if the call is coming from a different thread? Eg, if you call a method from a different thread, it might dispatch the call to the platform thread asynchronously, but if you call that method from the platform thread it can do the work synchronously. That could cause behavioral differences.

[brianquinlan]

FWIW, the invocation point is:

http/pkgs/cupertino_http/lib/src/cupertino_web_socket.dart

Line 258 in ef05b37

_task.cancelWithCloseCode(code, utf8.encode(reason).toNSData());

[liamappelbe]

Does it work correctly if you move that call to a different isolate using Isolate.run?

[brianquinlan]

Does it work correctly if you move that call to a different isolate using Isolate.run?

Yes! I can't see any documentation for NSURLSession saying that its method are sensitive to the thread that runs them. Any ideas?

[liamappelbe]

Yes! I can't see any documentation for NSURLSession saying that its method are sensitive to the thread that runs them. Any ideas?

My guess is it's only sensitive to the thread in the sense that it changes the order that certain events are sent/received in. Are there any assumptions you're making about event ordering, eg in other callbacks that are called in this flow?

[brianquinlan]

Yes! I can't see any documentation for NSURLSession saying that its method are sensitive to the thread that runs them. Any ideas?

My guess is it's only sensitive to the thread in the sense that it changes the order that certain events are sent/received in. Are there any assumptions you're making about event ordering, eg in other callbacks that are called in this flow?

It's hard to discount that possibility but I've added delays around the interesting parts of the flow to force particular timings. In both the successful and unsuccessful cases, the same calls are made in the same order and the same callbacks are received in the same order.