This is exposed when trying to change how C++ Mojo bindings schedule message dispatch tasks. To copypasta myself from an e-mail thread regarding the CastRemotingSenderTest (both tests are essentially identical)...

The flow of events set forth by the first part of the test is:

1. Send SendFrame(16) message to CastRemotingSender
2. Send SendFrame(32) message to CastRemotingSender
3. Send CancelInFlightData message to CastRemotingSender
4. Pump message loop
5. Expect the CastRemotingSender's next frame data size to be 16 bytes

With the current Mojo behavior, the detailed event flow turns out to be:

1. With a scheduled task, CastRemotingSender's Binding is notified that it has messages

2. SendFrame(16) is read and dispatched. ReadFrame(16) is executed on the CastRemotingSender, setting next_frame_data_ size to 16, and ultimately issuing a Read on data_pipe_reader_. This will synchronously invoke OnFrameRead, because data is already available on the data pipe consumer handle. The ReadFrame(16) task is popped off input_queue_ and a task is posted to ProcessNextInputTask.

3. SendFrame(32) is read and dispatched because we're still executing the singular Binding dispatch task (from #1) to flush all available messages. input_queue_ has 2 more tasks appended to it (another ReadFrame and TrySendFrame), bringing it to a total of 3 tasks.

4. CancelInFlightData is read and dispatched and input_queue_discards_remaining_ is set to 2.

5. The ProcessNextInputTask task from #2 is executed, discarding the first TrySendFrame and posting another ProcessNextInputTask task, which then discards the subsequent ReadFrame(32) input task. The rest of the task chain is irrelevant.

6. The test passes this expectation[1] because the next frame data size is still 16 bytes. It is unclear to me why the test is verifying this expectation as it does not seem like something the implementation is designed to guarantee.


With the new Mojo behavior:

1. SendFrame(16) is read and dispatched and behaves exactly as in #2 above, immediately reading data from the pipe and invoking OnFrameRead. next_frame_data_ size is 16, input_queue_ ends up with TrySendRead only, and a task is posted to ProcessNextInputTask.

2. Before returning, the task which dispatched SendFrame, now also flushes the rest of the messages out of the pipe, queueing two tasks to dispatch the SendFrame(32) and CancelInFlightData messages.

3. The ProcessNextInputTask task from #1 executes now, ultimately executing TrySendFrame() from input_tasks_.

4. SendFrame(32) is dispatched, enqueueing new ReadFrame(32) and TrySendFrame input tasks. No input tasks were queued, so this calls ProcessNextInputTask immediately, thus invoking ReadFrame(32) and ultimately setting next_frame_data_ size to 32.

5. CancelInFlightData is dispatched but it doesn't really matter at this point

6. The test fails this expectation[1] because the next frame data size is 32 bytes.


[1] https://cs.chromium.org/chromium/src/components/mirroring/browser/cast_remoting_sender_unittest.cc?rcl=a1222f2c291d48aa7b83d4a1db41a51a05fa1159&l=369