Feat(logs) upgrade mothership chat messages to error

[TheodoreSpeaks]

Summary

Upgrade mothership message logs to error to surface them in logs.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation
• Other: ___________

Testing

Validated that local service still runs. Validated flow shows no secrets

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

Screenshots/Videos

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs	Ready	Preview, Comment	Mar 25, 2026 10:42pm

[cursor]

PR Summary

Medium Risk
Changes many high-frequency Copilot/Mothership API and orchestrator logs from info to error, which can increase log volume/cost and potentially trigger alerting or error-rate monitors without changing request behavior.

Overview
Elevates Copilot/Mothership observability logs to error level. The PR switches numerous logger.info calls to logger.error across Copilot chat endpoints (including stream resume), the Mothership chat start route, the headless v1 chat route, payload building (MCP tool discovery), streaming/orchestration lifecycle, SSE request-id mapping, and tool execution logging.

No functional behavior changes are introduced beyond log severity (plus minor formatting around one tool-execution log call).

^{Written by Cursor Bugbot for commit 8f74750. This will update automatically on new commits. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Normal flow logged as errors

High Severity

This change upgrades many successful-path logger.info messages to logger.error, so routine requests emit ERROR logs on stderr. That misclassifies healthy operations as failures and will flood error-based monitoring, making real failures harder to detect.

Additional Locations (2)

• apps/sim/app/api/copilot/chat/route.ts#L195-L648
• apps/sim/app/api/copilot/chat/stream/route.ts#L38-L127

 

[TheodoreSpeaks]

intended

[cursor]

Tool parameters exposed in error logs

High Severity

toolCall.params is now logged with logger.error at tool start. Because production only emits ERROR by default, arbitrary tool input that was previously suppressed is now persisted in production logs, risking leakage of secrets or sensitive user data.

 

[greptile-apps]

Greptile Summary

This PR upgrades 30+ copilot/mothership chat log statements from logger.info to logger.error in order to surface them in a production monitoring setup. While the underlying goal is reasonable (making key request lifecycle events visible in logs), the implementation uses logger.error indiscriminately for all log levels — including successful outcomes, normal flow events, and user-initiated actions.

Key concerns:

• Success events logged as errors: 'Tool execution succeeded', 'Tool output written to file/table', 'Generated and saved title', 'Completing copilot orchestration', and 'Returned non-streaming response' are all positive outcomes that should never appear in an error stream.
• Normal flow events logged as errors: 'Starting copilot orchestration', 'Starting orchestration loop iteration', 'Received chat POST', 'Contexts processed for request' fire on every chat message and will generate dozens of error-level log entries per request.
• User-initiated events logged as errors: 'Stream aborted by explicit stop' and 'Stopping orchestration because request was aborted' reflect expected user behavior (pressing cancel), not error conditions.
• Observability impact: Error monitoring dashboards (Sentry, Datadog, etc.) will be flooded with non-error events on every chat interaction, making it very difficult to detect real errors and leading to alert fatigue.

The better path to making these logs visible is either to raise only the specific diagnostic checkpoints to logger.warn (e.g., start-of-request and async-resume events), or to adjust the log-level filter/sampling configuration to include info-level logs from the copilot namespace.

Confidence Score: 3/5

• Not safe to merge without revising the log-level strategy — success events and normal flow events logged as errors will create sustained alert noise in production error monitoring.
• The PR does not break user-facing functionality or introduce data loss, but it introduces a systemic observability problem: every successful chat interaction will generate numerous logger.error entries covering routine operations like 'Tool execution succeeded' and 'Starting orchestration loop iteration'. This will saturate error dashboards and erode the signal-to-noise ratio for real errors in production — a likely production reliability concern per the confidence rubric.
• apps/sim/lib/copilot/orchestrator/index.ts and apps/sim/lib/copilot/orchestrator/sse/handlers/tool-execution.ts have the most widespread misuse; apps/sim/lib/copilot/chat-streaming.ts has the user-abort false-positive.

Important Files Changed

Filename	Overview
apps/sim/lib/copilot/orchestrator/index.ts	All 16 logger.info calls converted to logger.error; includes normal loop iterations, async continuation handling, and orchestration start/completion — all non-error events that will flood error monitoring on every chat interaction.
apps/sim/lib/copilot/orchestrator/sse/handlers/tool-execution.ts	Contains the most semantically incorrect change — 'Tool execution succeeded' logged as logger.error. Also logs file/table write successes as errors.
apps/sim/app/api/copilot/chat/route.ts	8 logger.info → logger.error conversions covering request receipt, context processing, title generation success, and response return — all normal lifecycle events.
apps/sim/lib/copilot/chat-streaming.ts	Logs user-initiated stream abort ('Stream aborted by explicit stop') as logger.error, causing false-positive error alerts on every user cancel action.
apps/sim/app/api/copilot/chat/stream/route.ts	4 logger.info → logger.error conversions for stream resume/lookup/batch/flush operations — all normal informational events during stream recovery.
apps/sim/app/api/mothership/chat/route.ts	Single logger.info → logger.error change for the mothership chat start request receipt — the primary motivating change of this PR.
apps/sim/app/api/v1/copilot/chat/route.ts	Single logger.info → logger.error change for the headless copilot chat start request receipt.
apps/sim/lib/copilot/chat-payload.ts	Single change logging successful MCP tool addition to payload as an error instead of info.
apps/sim/lib/copilot/orchestrator/sse/handlers/handlers.ts	Single change logging the request_id mapping event as error; more borderline since it's a significant diagnostic checkpoint, but still an informational event.

Sequence Diagram

sequenceDiagram
    participant Client
    participant ChatRoute as /api/copilot/chat
    participant Orchestrator as orchestrateCopilotStream
    participant SSEHandlers as SSE Handlers
    participant ToolExec as executeToolAndReport
    participant Monitor as Error Monitoring

    Client->>ChatRoute: POST /chat
    ChatRoute->>Monitor: logger.error("Received chat POST") ⚠️
    ChatRoute->>Orchestrator: orchestrateCopilotStream()
    Orchestrator->>Monitor: logger.error("Starting copilot orchestration") ⚠️
    loop Each iteration
        Orchestrator->>Monitor: logger.error("Starting orchestration loop iteration") ⚠️
        Orchestrator->>SSEHandlers: process SSE events
        SSEHandlers->>ToolExec: executeToolAndReport()
        ToolExec->>Monitor: logger.error("Tool execution started") ⚠️
        ToolExec->>Monitor: logger.error("Tool execution succeeded") ⚠️
        Orchestrator->>Monitor: logger.error("Completed orchestration loop iteration") ⚠️
    end
    Orchestrator->>Monitor: logger.error("Completing copilot orchestration") ⚠️
    ChatRoute->>Monitor: logger.error("Returning non-streaming response") ⚠️
    ChatRoute->>Monitor: logger.error("Generated and saved title") ⚠️
    ChatRoute-->>Client: 200 OK

    Note over Monitor: Every successful chat request<br/>generates ~10+ error-level entries

Loading

Comments Outside Diff (3)

1. apps/sim/lib/copilot/orchestrator/sse/handlers/tool-execution.ts, line 692-699 (link)

   Success events logged as errors

   'Tool execution succeeded' at line 692 is the clearest semantic inversion in this PR — a successful outcome is now classified as an error. The same issue appears throughout this PR for other success/informational messages: 'Tool output written to file' (line 190), 'Tool output written to table' (line 400), 'Read output written to table' (line 527), and 'Completing copilot orchestration' in orchestrator/index.ts.

   Logging successful operations at error level means error monitoring systems (Sentry, Datadog, etc.) will fire alerts on every successful tool execution, every successful file write, and every completed orchestration — making it nearly impossible to distinguish real failures from the noise.

   If the goal is to surface these logs in a production monitoring setup that filters by level, consider using logger.warn for genuinely interesting (but non-error) operational checkpoints, or adjusting the log-level filter to include info for these specific namespaces.

2. apps/sim/lib/copilot/orchestrator/index.ts, line 138-146 (link)

   Normal flow events logged as errors

   'Starting copilot orchestration' is a routine informational event that fires on every single chat interaction — it is not an error condition. The same pattern applies to 'Starting orchestration loop iteration' (line 157), 'Completed orchestration loop iteration' (line 203), 'No async continuation pending; finishing orchestration' (line 243), 'Resuming async tool continuation' (line 476), and 'Marking async tool calls as delivered' (line 212).

   Logging every orchestration iteration at error level means every chat message will generate multiple error-level log entries for normal flow. This will create substantial alert noise in error monitoring dashboards and, over time, lead to alert fatigue that causes real errors to be missed.

3. apps/sim/app/api/copilot/chat/route.ts, line 619-623 (link)

   Successful title generation logged as error

   'Generated and saved title: ${title}' is a success confirmation after a database write succeeded. This should not be an error. Similarly, 'Returning non-streaming response' (line 648), 'Retrieved chat ${chatId}' (line ~780), and 'Received chat POST' (line ~196) in this file are all normal request-lifecycle events.

_{Reviews (1): Last reviewed commit: "Fix lint" | Re-trigger Greptile}

[greptile-apps]

User-initiated abort logged as error

'Stream aborted by explicit stop' is triggered when a user intentionally cancels a request — it is expected, non-erroneous behavior. Logging it as error will create false positive alerts every time a user presses a stop button. The same applies to 'Stopping orchestration because request was aborted' in orchestrator/index.ts line 225.

Suggested change

	logger.error(
	appendCopilotLogContext('Stream aborted by explicit stop', { requestId, messageId })
	)
	logger.info(
	appendCopilotLogContext('Stream aborted by explicit stop', { requestId, messageId })
	)