Hey everyone! 👋 Has anyone else run into persistent scan failures with Braintrust on a large monorepo? We're hitting a wall and I'm hoping the collective brainpower here can help.
Our setup is a JavaScript/TypeScript monorepo using pnpm workspaces. The structure is pretty standard, with several internal packages and a couple of app directories. The scan starts fine but consistently fails about halfway through. The error in the dashboard is pretty generic: "Scan failed due to an internal error." Not super helpful!
Here's what we've tried so far:
* Verified our Braintrust API token and network connectivity are fine.
* Increased the scan timeout settings in our project config.
* Tried scanning individual subdirectories instead of the root—those sometimes work, but it's not a real solution for us.
Our `.braintrust/config.yml` is pretty basic, mostly just specifying the root and excluding `node_modules`.
**Main question:** Are there known limitations or specific configurations for monorepos? Could it be memory-related? We're leaning towards something timing out or hitting a resource limit, but the logs aren't giving us a smoking gun.
Tagging a few folks who often have great insights on setup stuff: @alex_c @devops_joy. Hope this helps!
The generic "internal error" message often masks resource exhaustion, especially with pnpm workspaces. While you've ruled out network and timeouts, have you checked the memory footprint during the scan? Braintrust's indexer can struggle with symlinked node_modules across multiple packages, creating a path resolution loop that consumes heap space before failing.
A practical step is to instrument the scan process locally, if possible, to monitor memory usage. Alternatively, try a more aggressive ignore pattern in your config.yml. Excluding build output directories and lockfiles sometimes prevents the parser from traversing non-essential symbolic links that blow up the dependency graph.
You mentioned scanning subdirectories works. That points to a total project complexity threshold. You might need to segment your scans logically, like by business unit or package group, and then merge the results. It's a workflow tax, but it provides data continuity while you pressure the vendor for better monorepo support. Have you opened a ticket with their support and included a sanitized project structure diagram?
Yeah, the resource exhaustion angle makes a lot of sense. I've seen similar behavior in other tools when they hit a huge, symlinked node_modules forest.
> try a more aggressive ignore pattern in your config.yml
This was key for us. We ended up adding patterns for `**/dist`, `**/coverage`, `**/.next`, and even `pnpm-lock.yaml` to stop the scanner from trying to parse it as code. That cut the scan time in half and stopped the random failures.
Segmenting scans by package group is a decent workaround, but merging those results later for a unified view can get messy. It's a band-aid. I'd still push on that support ticket. In our case, sharing a simplified reproduction repo structure finally got their engineering team to replicate the issue.
Data is the new oil, but it's messy.
Great call on adding `pnpm-lock.yaml` to the ignore list, that's one a lot of folks miss. It's amazing how much time the scanner can waste trying to parse a lockfile as code.
I'd add one caveat from our experience: while aggressive ignore patterns are a lifesaver, they can sometimes mask a real bug in the scanner's symlink handling. We fixed our immediate failures with patterns, but also logged a ticket with the specific paths that were causing the loops. The team actually fixed it in a later release.
So yeah, absolutely do both - patch it now with your config, but don't let the support ticket drop. The reproduction repo is gold for them.
Measure twice, slice once.