Add proper error handling for API conversation history issues

[KJ7LNW]

Context

This PR adds detailed debug logging to the readApiMessages function to help diagnose "Unexpected: No existing API conversation history" errors.

Implementation

Added logging for three scenarios:

1. When the API conversation history file exists but contains an empty array
2. When the old history file exists but contains an empty array
3. When neither history file is found (already implemented)

How to Test

When encountering the "Unexpected: No existing API conversation history" error, check the Developer Tools console (Help > Toggle Developer Tools > Console tab) for debug messages with the format:
[Roo-Debug] readApiMessages: ...

These logs will show the taskId and file path, helping to diagnose the issue.

Screenshots

N/A - Console logging only

Get in Touch

Discord: KJ7LNW

does not completely fix #4311 but it may provide debug output that may help us fix it from other users.

---

Important

Adds detailed debug logging to readApiMessages in apiMessages.ts for diagnosing issues with API conversation history files.

• Debug Logging:
  • Adds detailed debug logging to readApiMessages in apiMessages.ts for diagnosing missing or empty API conversation history files.
  • Logs when the history file exists but is empty, and when the old history file exists but is empty.
  • Logs when neither the new nor old history file is found.
• Error Handling:
  • Catches JSON parsing errors and logs them with taskId and file path details.
  • Ensures old history file is not deleted if parsing fails.

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

[hannesrudolph]

See notes on the issue as to why I moved this to draft

[KJ7LNW]

I just wanted to provide the steps I took for troubleshooting and case it helps someone else along the way.

These debug prints are non-intrusive, uncommon, only trigger upon error, and only serve to help troubleshoot this problem if somebody else hits it.

IMHO, PRs like this should be merged quickly to help future troubleshooting by others. (Someday if I clean up and delete the branch, then this research could be lost.)

[KJ7LNW]

@cte - Windows test error is probably unrelated to this pull request - do you know what is going on there?

[daniel-lxs]

Looking at this PR, I noticed the debug logging is only written to console.error. Have you considered propagating these error details up to the actual error that users see?

Currently, when readApiMessages() encounters an empty file or missing file, it logs to console but returns []. Then in Task.ts line 922, it throws a generic error: "Unexpected: No existing API conversation history".

Wouldn't it be more helpful if the error message included the specific reason? For example:

• "No existing API conversation history: File not found at ~/.config/.../api_conversation_history.json"
• "No existing API conversation history: File exists but is empty at ~/.config/.../api_conversation_history.json"
• "No existing API conversation history: JSON parsing error at ~/.config/.../api_conversation_history.json"

This way users would immediately know what went wrong without needing to check developer console logs. The debug info could either be:

1. Returned as part of a result object from readApiMessages()
2. Thrown as specific error types that can be caught and re-thrown with context

What do you think about enhancing the error propagation in addition to the console logging?

[KJ7LNW]

Looking at this PR, I noticed the debug logging is only written to console.error. Have you considered propagating these error details up to the actual error that users see?

It is a good idea, however I do not really want to put a lot more work into this. Is there a VS Code function that can replace console.error to provide a simple pop-up? if there is, then probably all console.{warn,error} occurrences in the code base should be standardized to use such a mechanism, and then .roo/rules/logging-rules.md needs to be created to instruct future AI debug use to use the same mechanism.

The intention of this PR was just to provide a little more information to possibly help others by simple debug; in this case the review process is introducing unnecessary complexity to what was intended as trivial.

Sometimes when troubleshooting an issue if I do not find a complete solution, I will create a pull request with whatever instrumentation led me there, in hopes that someone else can report with additional information. The error framework that you suggest as a great idea, and maybe it should be taken on by another developer in a separate pull request to streamline PRs like this in the future.

If you (or someone else) would like to implement such a thing then please do, but I think if this pull request is not acceptable in its current state than we should close it because I do not have the bandwidth to take that on at the moment.

[daniel-lxs]

Looks good to me, this will help us understand what might be going on when tasks disappear in some cases.