Undefined filename in require

[cursor]

Replace synchronous createRequire with asynchronous dynamic import() for Sentry loading.

This fixes a TypeError in bundled CommonJS contexts where __filename is undefined, causing createRequire to receive an invalid filename argument. The new approach uses dynamic import() which is more robust in various module environments and gracefully handles Sentry loading.

---

 

---

Note

Shifts Sentry integration in logger.ts to asynchronous dynamic import with safe, single-attempt loading and caching.

• Replaces createRequire/sync require('@sentry/node') with await import('@sentry/node'), adding sentryLoadAttempted to prevent repeated loads
• Updates withSentry to fire-and-forget async loading and safely invoke callbacks without throwing
• Preserves environment-based disabling and test-environment suppression, with unchanged logging behavior to stderr

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

[cursor]

Cursor Agent can help with this pull request. Just @cursor in comments and I'll start working on changes in this branch.
_{Learn more about Cursor Agents}

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/cameroncooke/XcodeBuildMCP/xcodebuildmcp@168

commit: a9cad89

[cursor]

Early calls during Sentry loading silently dropped

Medium Severity

The loadSentryAsync function sets sentryLoadAttempted = true before the async import() completes. Any log calls that occur while the first import is still in progress will find sentryLoadAttempted is true but cachedSentry is still null, causing the function to return null immediately. This means error messages logged during the Sentry loading window are silently lost and never sent to Sentry. The loading promise could be stored and returned to subsequent callers to ensure all callbacks execute once loading completes.

 

[cameroncooke]

@cursor fix

[cursor]

❌ Unable to add follow-up after multiple attempts. The agent may be experiencing issues.

Please try again later or Open in Web to view the status.

---

 

_{Learn more about Cursor Agents}

[cameroncooke]

@cursor fix

[cursor]

❌ Unable to add follow-up after multiple attempts. The agent may be experiencing issues.

Please try again later or Open in Web to view the status.

---

 

_{Learn more about Cursor Agents}

[sentry]

Bug: The switch to asynchronous Sentry loading in withSentry creates a race condition, causing error logs to be lost if the process exits before the async operation completes.
_{Severity: CRITICAL | Confidence: High}

🔍 Detailed Analysis

The withSentry function was changed to load Sentry asynchronously using loadSentryAsync().then(...). This defers the execution of the callback, which sends the error report, to a future microtask. In scenarios where the application exits shortly after logging an error, such as in fatal error handlers that call process.exit(), the process will terminate before the microtask queue is processed. This will cause the error log to be lost and never sent to Sentry, defeating the purpose of the error reporting mechanism, especially for unhandled exceptions where immediate process termination is common.

💡 Suggested Fix

Revert withSentry to its previous synchronous implementation. Since @sentry/node is already loaded synchronously in other parts of the application, the asynchronous loading is unnecessary. If async loading must be kept, error handlers should be modified to await the logging operation's completion before exiting the process.

🤖 Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: src/utils/logger.ts#L63-L72

Potential issue: The `withSentry` function was changed to load Sentry asynchronously
using `loadSentryAsync().then(...)`. This defers the execution of the callback, which
sends the error report, to a future microtask. In scenarios where the application exits
shortly after logging an error, such as in fatal error handlers that call
`process.exit()`, the process will terminate before the microtask queue is processed.
This will cause the error log to be lost and never sent to Sentry, defeating the purpose
of the error reporting mechanism, especially for unhandled exceptions where immediate
process termination is common.

_{Did we get this right? 👍 / 👎 to inform future reviews.
Reference ID: 530353}