fix(logging): replace console.warn with logger in stars API route

[badhra-ajaz]

Problem

The /api/stars route uses console.warn() for error and failure logging, while every other API route in the codebase uses createLogger from @sim/logger. This means warning output from this route bypasses the structured logging pipeline.

Before:

console.warn('GitHub API request failed:', response.status)
console.warn('Error fetching GitHub stars:', error)

Fix

Replaced both console.warn() calls with logger.warn() using a StarsAPI logger instance, matching the pattern used in all other API routes (e.g., EnvironmentAPI, SkillsAPI, CreditsAPI).

import { createLogger } from '@sim/logger'
const logger = createLogger('StarsAPI')

// ...
logger.warn('GitHub API request failed:', response.status)
logger.warn('Error fetching GitHub stars:', error)

[cursor]

PR Summary

Low Risk
Low risk logging-only change: replaces console.warn with logger.warn in a single API route, with no behavior changes to responses or external calls.

Overview
Updates the /api/stars route to use structured logging by introducing a StarsAPI logger via createLogger and replacing both warning console.warn calls with logger.warn for GitHub API failures/exceptions.

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

[vercel]

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

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Mar 11, 2026 4:38am

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

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

[cursor]

Production warnings silently suppressed by logger level filtering

Medium Severity

Switching from console.warn to logger.warn silently suppresses these warnings in production. The @sim/logger defaults to LogLevel.ERROR in production, so WARN-level messages are filtered out unless LOG_LEVEL is explicitly overridden. Previously, console.warn always emitted output. GitHub API failures and fetch errors will now go unnoticed in production logs.

Additional Locations (1)

• apps/sim/app/api/stars/route.ts#L34-L35

 

[greptile-apps]

Greptile Summary

This PR replaces two console.warn() calls in apps/sim/app/api/stars/route.ts with structured logger.warn() calls using a StarsAPI createLogger instance, aligning this route with the logging conventions used across all other API routes in the codebase.

Key observations:

• The import order and logger instantiation correctly follow the established pattern (e.g., EnvironmentAPI, SkillsAPI).
• The @sim/logger package defaults to minLevel: ERROR in production, meaning both logger.warn calls will be silenced in production unless a LOG_LEVEL env override is configured — a behavioral difference from the previous console.warn which always printed. Consider using logger.error instead to preserve production visibility of GitHub API failures.

Confidence Score: 4/5

• Safe to merge with low risk; the behavioral change in production logging is worth confirming before landing.
• The change is minimal and structurally correct, matching the pattern used across all other API routes. The only concern is that logger.warn is suppressed in production by the logger's default minLevel: ERROR, which silently changes the observability of GitHub API failures compared to the original console.warn. The author should make an informed decision about whether to use logger.error instead or explicitly set LOG_LEVEL=WARN in production.
• apps/sim/app/api/stars/route.ts — confirm intended log level (warn vs. error) given production log suppression behavior

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[GET /api/stars] --> B[fetch GitHub API]
    B --> C{response.ok?}
    C -- No --> D["logger.warn('GitHub API request failed:', status)"]
    D --> E[Return fallback count]
    C -- Yes --> F[Parse stargazers_count]
    F --> G[Return formatted count]
    B -- throws --> H["logger.warn('Error fetching GitHub stars:', error)"]
    H --> E

    style D fill:#ffe066,stroke:#e6b800
    style H fill:#ffe066,stroke:#e6b800

    subgraph logger["@sim/logger behavior"]
        direction LR
        L1[development → WARN ✅ logged]
        L2[production → WARN ❌ suppressed by default]
        L3[test → WARN ❌ suppressed]
    end

    D -.-> logger
    H -.-> logger

Loading

_{Last reviewed commit: 1de514b}

[greptile-apps]

Warn-level logs are suppressed in production by default

The @sim/logger package sets minLevel: ERROR in production environments, which means both logger.warn() calls will be silently dropped in production unless a LOG_LEVEL env override is configured. Prior to this change, console.warn() always printed regardless of environment.

This means GitHub API failures — both non-OK responses and thrown exceptions — will be invisible in production logs by default. Consider whether these should be elevated to logger.error() to ensure they remain visible in production, or confirm that LOG_LEVEL=WARN is set in your production environment to preserve the previous behavior.

Suggested change

	logger.warn('GitHub API request failed:', response.status)
	return NextResponse.json({ stars: formatStarCount(19400) })
	}
	const data = await response.json()
	return NextResponse.json({ stars: formatStarCount(Number(data?.stargazers_count ?? 19400)) })
	} catch (error) {
	console.warn('Error fetching GitHub stars:', error)
	logger.warn('Error fetching GitHub stars:', error)
	logger.error('GitHub API request failed:', response.status)

and

Suggested change

	logger.warn('GitHub API request failed:', response.status)
	return NextResponse.json({ stars: formatStarCount(19400) })
	}
	const data = await response.json()
	return NextResponse.json({ stars: formatStarCount(Number(data?.stargazers_count ?? 19400)) })
	} catch (error) {
	console.warn('Error fetching GitHub stars:', error)
	logger.warn('Error fetching GitHub stars:', error)
	logger.error('Error fetching GitHub stars:', error)