fix: Preserve parent-child relationship when cancelling subtasks

[cannuri]

Context

This commit fixes an issue where subtasks weren't properly reporting back to parent tasks when cancelled and resumed. Previously, when a subtask was cancelled and a new task was started with the same message, the parent task would incorrectly resume, causing unexpected behavior.

This fixes #1547

Implementation

The fix:

1. Stores parent-child relationship information before cancelling a task
2. Restores this relationship after task reinitialization
3. Ensures parent tasks only resume when explicitly instructed to do so

This approach maintains the correct task hierarchy throughout the cancellation and resumption process, preventing parent tasks from automatically resuming when unrelated tasks with similar messages are started.

How to Test

1. Create a task and tell it to create a subtask for something
2. In the subtask, press cancel, then resume the subtask
3. The subtask will now report back to the parent task

[changeset-bot]

⚠️ No Changeset found

Latest commit: 6ce8e56

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[samhvw8]

cool, lgtm :D

[cte]

@cannuri - Can you take a look at the integration test? It's not working in CI and I can't get it to work locally.

[cannuri]

@cannuri - Can you take a look at the integration test? It's not working in CI and I can't get it to work locally.

@cte Oh. I thought it passed CI already. Will look into it right away

[cte]

@cte Oh. I thought it passed CI already. Will look into it right away

I think there's a race condition when attempting to validate messages for different tasks. For example, if you spawn a subtask and then immediately look for a particular message in the parent task's messages... you'll find that the messages array will switch from the parent messages to the child messages as soon as the subtask becomes the primary Cline instance. Whether or not you get the message you are looking for probably depends on the polling interval. At any rate, I think we need a more reliable way to subscribe to task events and avoid using the message array directly. My suggestion is to turn RooCodeAPI into an EventEmitter so that you can subscribe to specific events by task id. I can help with that if you'd like (or feel free to take a stab at it).

[cte]

@cte Oh. I thought it passed CI already. Will look into it right away

Also, I think the e2e tests aren't run on branches on forks (since the fork won't have access to the OpenRouter API key stored as a secret in GitHub), so it will look like CI passed until your branch gets merged.