fix: handle pending ask operations during checkpoint restore

[roomote]

This PR attempts to address Issue #8177. Feedback and guidance are welcome.

Problem

Users were experiencing "Error asking question: Current ask promise was ignored" errors when restoring checkpoints, particularly on Windows 11.

Solution

The fix handles pending ask operations before checkpoint restoration by:

1. Checking if there are any pending ask operations (indicated by lastMessageTs)
2. Calling handleWebviewAskResponse with a dummy response to unblock any waiting promises
3. This prevents the "Current ask promise was ignored" error from being thrown

Changes

• Modified checkpointRestoreHandler.ts to handle pending ask operations for both delete and edit operations
• Added comprehensive test coverage with 3 new test cases to verify the fix

Testing

• All existing tests pass
• Added new tests specifically for pending ask scenarios
• Tests verify that pending asks are properly resolved before checkpoint restoration

Fixes #8177

---

Important

Fixes error during checkpoint restoration by handling pending ask operations in handleCheckpointRestoreOperation.

• Behavior:
  • Fixes error "Current ask promise was ignored" during checkpoint restoration by handling pending ask operations in handleCheckpointRestoreOperation.
  • Checks for pending asks using lastMessageTs and resolves them with handleWebviewAskResponse.
  • Applies to both delete and edit operations.
• Testing:
  • Adds 3 new test cases in checkpointRestoreHandler.spec.ts to verify handling of pending ask operations.
  • Tests ensure pending asks are resolved before checkpoint restoration.
• Misc:
  • Modifies checkpointRestoreHandler.ts to include logic for handling pending asks before restoration.

^{This description was created by for 760ef23. You can customize this summary. It will automatically update as commits are pushed.}

[roomote]

Reviewing my own code is like debugging in a mirror - everything looks backwards but the bugs are still mine.

[roomote]

Is using lastMessageTs the most reliable way to detect pending ask operations? This property could be set for other reasons. Consider adding a more explicit flag like hasPendingAsk to avoid potential false positives and make the intent clearer.

[roomote]

The choice to always use "messageResponse" with empty strings to clear pending asks might not be appropriate for all ask types. Could we either:

1. Use a more generic cancellation approach
2. Document why "messageResponse" is the universally correct choice here
3. Consider different response types based on the pending ask type?

[roomote]

For delete operations, we're now handling pending asks BEFORE aborting the task, which changes the original flow. Have we verified this doesn't introduce any side effects with the abort process? The order of operations can be critical in async cleanup scenarios.

[roomote]

Consider extracting this pending ask handling logic into a separate helper method like clearPendingAskOperations(currentCline) for better code organization and potential reusability. This would also make the main function cleaner and the intent more explicit.

[roomote]

Good test coverage! These tests effectively verify the pending ask handling for both delete and edit operations, as well as the case where no pending ask exists. Consider adding an edge case test where lastMessageTs is set to 0 or a very old timestamp to ensure the logic handles all scenarios correctly.

[daniel-lxs]

Closing for now, no repro steps