[Tracking] Personal assistant Bot issues encountered on TypeScript main #6482

What happened

This issue records problems I have personally encountered while using the personal assistant Bot on TypeScript main. I will keep it updated with reproduction conditions, investigation results, and resolution status.

As feature development moves to rust-preview, these observations can serve both as maintenance records for the current version and as regression references when the corresponding capabilities are implemented in Rust.

Related implementation and capability inventory: #6244, #6413.

The reproductions and validation below concern the TypeScript implementation. The corresponding Rust behavior has not been verified.

How to reproduce

1. Quote-comment feedback blocks subsequent judgement

Steps

1. Enable proactive discovery for the personal assistant and wait for it to actually deliver a discovery message.
2. Quote that message and write feedback such as “Please stop tracking this task” in the quote comment, leaving the additional message body empty.
3. The Bot calls DiscoveryFeedback to associate that reply with the delivered message.
4. Wait for the next proactive-discovery cycle to process the feedback.

This is a valid message structure, for example:

{
  "text": "",
  "quotes": [
    {
      "text": "Task progress",
      "comment": "Please stop tracking this task"
    }
  ]
}

Actual result

The judgement workflow throws:

Error: Feedback text and time required

In the actual record, the timestamp is valid; it is the extracted feedback text that is empty.

BotStore.discoveryFeedback() only reads displayText ?? text, omitting quotes[].comment. The notebook's nonempty-text validation then rejects the feedback.

The impact extends beyond this one reply:

• Subsequent heartbeat attempts encounter the same feedback and fail before invoking the judgement model.
• A later clarification sent as an ordinary text message is also blocked by the earlier failure.
• Restarting encounters the same persisted record.
• I observed five consecutive failed cycles while the scheduler remained enabled: true.

An enabled schedule therefore did not mean that discovery was successfully completing work. Sending another clarification did not unblock the earlier record.

Expected result

Feedback written by the user in a quote comment should enter the feedback workflow. Existing affected records should be recoverable, later clarifications should continue to be processed, and already-processed feedback history should be preserved without duplicate imports.

Current validation status

A local patch has been validated:

• The new regression test reproduced the original error before the fix and passed after it.
• Coverage includes recovery after restart, later clarifications, messages containing both body text and quote comments, and repeated imports.
• The assistant-related suites passed 407 tests, with 0 failures.
• After restarting with the original workspace, both previously blocked feedback records were actually processed. The subsequent scheduled cycle completed successfully, lastError cleared, and the failure count returned to zero.

The local patch has not been submitted upstream.

2. Insufficient diagnostics for response-processing failures after HTTP 200

Conditions and frequency

While running proactive discovery and related investigation tasks through the configured model connection, the same failure shape occurred twice within approximately 34 minutes:

• 2026-10-29 23:32:22, UTC+8
• 2026-10-30 00:06:49, UTC+8

The persisted error information was:

{
  "code": "200",
  "message": "Failed to process successful response (status=200)",
  "reason": "unknown",
  "retry": {
    "because": "policy",
    "decision": "declined"
  }
}

Actual result

The affected execution ended. The available records did not retain enough information about the original cause to establish where these two response-processing failures occurred.

Not automatically retrying unknown follows the current policy. The outstanding questions in this entry are the original failure cause and whether the diagnostics are sufficient to locate it.

Current validation status

• Sanitized diagnostics have been added locally, with the retry policy unchanged.
• A controlled connection interruption after HTTP 200 was classified as a retryable network error.
• One explicitly authorized replay of the original discovery workflow completed all 14 model requests across exploration and judgement without reproducing the original failure.

At present, the two real failures are confirmed observations; their specific cause still needs additional diagnostic evidence.

Expected result

These failures should retain sufficient sanitized information about the error class, failure phase, and cause chain to distinguish response parsing, transport, and other failures and assess the appropriate recovery behavior.

Environment

• Maka: source build based on TypeScript main@8dd205bab4792ce03193a1ddce5dea094cc3dd87
• Upstream source checked: main@85a1031c10d104456127f35aac1523b9ffb1a384
• OS: macOS 26.7.2
• Node.js: v24.19.0
• Surface: Desktop personal assistant Bot, proactive discovery, and background investigation tasks
• Configured model: deepseek/deepseek-v4.1-flash
• The quote-feedback fix and diagnostic additions are local modifications

Logs, screenshots, or additional context

I will add further problems I actually encounter here, with:

• reproduction steps or observed conditions;
• confirmed facts and remaining investigation questions;
• local validation, upstream resolution, and Rust verification status.

AI assistance: OpenAI Codex assisted with source inspection, reproduction, testing, and drafting this report. I reviewed this report before submitting it.

{
  "text": "",
  "quotes": [
    {
      "text": "任务进展",
      "comment": "这个任务不要再追踪了"
    }
  ]
}

Error: Feedback text and time required

{
  "code": "200",
  "message": "Failed to process successful response (status=200)",
  "reason": "unknown",
  "retry": {
    "because": "policy",
    "decision": "declined"
  }
}