`pkg/dds/test/dap/integration/debug_test` went from flaky -> Timeout

[derekxu16]

pkg/dds/test/dap/integration/debug_test went from flaky -> Timeout on unittest-asserts-release-mac-arm64

https://dart-ci.appspot.com/log/pkg-mac-release-arm64/unittest-asserts-release-mac-arm64/16606/pkg/dds/test/dap/integration/debug_test

@DanTup

[alexmarkov]

pkg/dds/test/dap/integration/debug_test turned flaky -> Timeout once again:

https://dart-ci.appspot.com/log/pkg-mac-release-arm64/unittest-asserts-release-mac-arm64/16762/pkg/dds/test/dap/integration/debug_test

[DanTup]

This looks like the same error reported at #60221:

<== [DAP] {"seq":5,"type":"response","command":"launch","request_seq":3,"success":true}
<== [DAP] {"seq":6,"type":"event","body":{"category":"stderr","output":"Could not start the VM service:\n"},"event":"output"}
<== [DAP] {"seq":7,"type":"event","body":{"category":"stderr","output":"\n"},"event":"output"}

I suspect the timeout is because when this happens, the service-info file is never written (and we sit waiting for it, because that's how we get the VM Service URI to connect to). It seems like the process never terminates in this state (if it did, I think we'd see an immediate failure and not a timeout).

(Edit: I've filed #60256 about the VM not terminating)

[DanTup]

Looks like this test recently went flaky again, although for a different reason:

https://dart-ci.firebaseapp.com/#showLatestFailures=false&test=pkg/dds/test/dap/integration/debug_test

https://dart-ci.appspot.com/log/pkg-mac-release/unittest-asserts-release-mac-x64/36321/pkg/dds/test/dap/integration/debug_test

00:05 �[32m+5�[0m�[33m ~1�[0m�[31m -1�[0m: debug mode receives thread, stopped, continued events during pause/resume �[1m�[31m[E]�[0m�[0m

  Expected: [
              'thread (reason: started, threadId: 1)',
              'stopped (reason: entry, threadId: 1, allThreadsStopped: false)',
              'continued (threadId: 1, allThreadsContinued: false)',
              'stopped (reason: step, threadId: 1, allThreadsStopped: false)',
              'continued (threadId: 1, allThreadsContinued: false)',
              'stopped (reason: step, threadId: 1, allThreadsStopped: false)',
              'continued (threadId: 1, allThreadsContinued: false)',
              'stopped (reason: step, threadId: 1, allThreadsStopped: false)',
              'continued (threadId: 1, allThreadsContinued: false)',
              'stopped (reason: step, threadId: 1, allThreadsStopped: false)',
              'continued (threadId: 1, allThreadsContinued: false)',
              'stopped (reason: exit, threadId: 1, allThreadsStopped: false)',
              'thread (reason: exited, threadId: 1)',
              'terminated'
            ]
    Actual: [
              'thread (reason: started, threadId: 1)',
              'continued (threadId: 1, allThreadsContinued: false)',
              'stopped (reason: step, threadId: 1, allThreadsStopped: false)',
              'continued (threadId: 1, allThreadsContinued: false)',
              'stopped (reason: step, threadId: 1, allThreadsStopped: false)',
              'continued (threadId: 1, allThreadsContinued: false)',
              'stopped (reason: step, threadId: 1, allThreadsStopped: false)',
              'continued (threadId: 1, allThreadsContinued: false)',
              'stopped (reason: step, threadId: 1, allThreadsStopped: false)',
              'continued (threadId: 1, allThreadsContinued: false)',
              'stopped (reason: exit, threadId: 1, allThreadsStopped: false)',
              'thread (reason: exited, threadId: 1)',
              'terminated'
            ]
     Which: at location [1] is 'continued (threadId: 1, allThreadsContinued: false)' instead of 'stopped (reason: entry, threadId: 1, allThreadsStopped: false)'

It appears that the pause-on-entry event was missing.

[DanTup]

The issue here seems to be that we have two paths to handling startup of an isolate that exists when we connect to the VM

1. It has no pause event, and we call _configureExistingIsolates which calls handleThreadStartup (with sendStoppedOnEntry: false)
2. It already has a PauseStart event and we call _handlePause which calls handleThreadStartup (with sendStoppedOnEntry: true)

Depending on which of these is true (which seems to be timing-dependent), we may or may not send the pause-on-entry.

It might be that the test should account for this, but I need to find out whether we actually want/expect this difference.