Feat(logs) upgrade mothership chat messages to error by TheodoreSpeaks · Pull Request #3772 · simstudioai/sim

TheodoreSpeaks · 2026-03-25T22:39:50Z

Summary

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

Type of Change

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 · 2026-03-25T22:39:55Z

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 · 2026-03-25T22:39:56Z

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 · 2026-03-25T22:43:50Z

apps/sim/lib/copilot/orchestrator/index.ts

      const continuation = context.awaitingAsyncContinuation
      if (!continuation) {
-        logger.info(withLogContext('No async continuation pending; finishing orchestration'))
+        logger.error(withLogContext('No async continuation pending; finishing orchestration'))


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

cursor · 2026-03-25T22:43:50Z

apps/sim/lib/copilot/orchestrator/sse/handlers/tool-execution.ts

+      toolName: toolCall.name,
+      params: toolCall.params,
+    }
+  )


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 · 2026-03-25T22:48:51Z

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

Comments Outside Diff (3)

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.
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.
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 · 2026-03-25T22:49:01Z

apps/sim/lib/copilot/chat-streaming.ts

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


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 })

)

* feat(log): enable info logs in staging and prod * Upgrade info logs to error for message route * Add to orchestrator, remove helm shennanigans * Fix lint --------- Co-authored-by: Theodore Li <[email protected]>

Theodore Li added 3 commits March 25, 2026 15:25

feat(log): enable info logs in staging and prod

a930538

Upgrade info logs to error for message route

ba56e4c

Add to orchestrator, remove helm shennanigans

d8c0bd4

TheodoreSpeaks changed the title ~~Feat/enable info logs~~ Feat(logs) upgrade mothership chat messages to error Mar 25, 2026

Fix lint

8f74750

vercel bot temporarily deployed to Preview March 25, 2026 22:41 Inactive

cursor bot reviewed Mar 25, 2026

View reviewed changes

TheodoreSpeaks merged commit 9d1b976 into staging Mar 25, 2026
12 checks passed

greptile-apps bot reviewed Mar 25, 2026

View reviewed changes

waleedlatif1 deleted the feat/enable-info-logs branch March 25, 2026 23:12

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feat(logs) upgrade mothership chat messages to error#3772

Feat(logs) upgrade mothership chat messages to error#3772
TheodoreSpeaks merged 4 commits intostagingfrom
feat/enable-info-logs

TheodoreSpeaks commented Mar 25, 2026

Uh oh!

vercel bot commented Mar 25, 2026 •

edited

Loading

Uh oh!

cursor bot commented Mar 25, 2026 •

edited

Loading

Uh oh!

cursor bot left a comment

Uh oh!

cursor bot Mar 25, 2026

Uh oh!

TheodoreSpeaks Mar 25, 2026

Uh oh!

cursor bot Mar 25, 2026

Uh oh!

Uh oh!

greptile-apps bot commented Mar 25, 2026 •

edited

Loading

Comments Outside Diff (3)

Uh oh!

greptile-apps bot Mar 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

TheodoreSpeaks commented Mar 25, 2026

Summary

Type of Change

Testing

Checklist

Screenshots/Videos

Uh oh!

vercel bot commented Mar 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cursor bot commented Mar 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Summary

Uh oh!

cursor bot left a comment

Choose a reason for hiding this comment

Uh oh!

cursor bot Mar 25, 2026

Choose a reason for hiding this comment

Normal flow logged as errors

Uh oh!

TheodoreSpeaks Mar 25, 2026

Choose a reason for hiding this comment

Uh oh!

cursor bot Mar 25, 2026

Choose a reason for hiding this comment

Tool parameters exposed in error logs

Uh oh!

Uh oh!

greptile-apps bot commented Mar 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Greptile Summary

Confidence Score: 3/5

Important Files Changed

Sequence Diagram

Comments Outside Diff (3)

Uh oh!

greptile-apps bot Mar 25, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

vercel bot commented Mar 25, 2026 •

edited

Loading

cursor bot commented Mar 25, 2026 •

edited

Loading

greptile-apps bot commented Mar 25, 2026 •

edited

Loading