AXON-1839 Cancel API is failing to respond:

[teg-atlassian]

What Is This Change?

In this PR, we address a subtle issue in how session cancellation is handled.

Currently, when a user cancels a session with Rovo Dev IDE:

1. Atlascode sends a cancel API request to Rovo Dev.
2. Only after Rovo Dev responds with a successful cancellation response does the Atlascode UI become ready to accept a new session.

This approach has a drawback: the user’s cancellation request is not fully honored until Rovo Dev completes its side of the cancellation. In practice, this can leave the user waiting and create the impression that the UI is still “stuck” on the old session.

In this PR, when the user cancels a session:

1. The Atlascode UI immediately aborts the current session and becomes ready to accept new session requests.
2. At the same time, Atlascode sends a cancel request to Rovo Dev.
3. Any pending responses from Rovo Dev that were sent before the cancellation (but not yet rendered) will still be displayed.

How Has This Been Tested?

npm run test:unit -- src/rovo-dev/rovoDevChatProvider.test.test.ts

Basic checks:

• npm run lint
• npm run test

Advanced checks:

• If Atlassian employee & Bitbucket changes: did you test with DC in mind? See Instructions

Recommendations:

• Update the CHANGELOG if making a user facing change

---

You don't have access to Rovo Dev Standard
Ask your organization admin to add you to Rovo Dev Standard.
More about code review errors

[marcomura]

I don't believe this solution will work.

If we immediately abort the session on cancellation, and we don't wait for the cancellation to be confirmed by Rovo Dev, a subsequent prompt will result in 4xx as Rovo Dev thinks a chat is already in progress.

[teg-atlassian]

marcomura thanks for the catch.

i have added code to address the case you mentioned
if a new prompt is sent while rovodev hasn't confirmed cancellation,

1. we queue the new prompt
2. we show a message to the user
3. wait until cancellation is confirmed and send the prompt