Fix Go extractor silent failures and improve error recovery

[allsmog]

Summary

Fixes silent failures in the Go extractor where OOM errors and file extraction failures would cause the entire extraction process to terminate without proper error logging.

Problem

The extractor was using log.Fatal() when file extraction failed, which caused:

1. Silent termination - entire extraction process stops on first error
2. Poor error visibility - OOM errors only visible in build-tracer logs, not extractor output
3. No partial extraction - remaining files not processed even if only one fails

This was particularly problematic for:

• Large codebases running into memory constraints
• Projects with a few problematic files that shouldn't block extraction of other files
• Debugging issues since errors weren't logged to extractor output

Solution

Minimal changes to improve error resilience:

1. Replace log.Fatal() with log.Printf() - log errors but continue extraction
2. Add panic recovery - catch OOM panics and other runtime errors in file extraction goroutines
3. Move cleanup to defer block - ensure semaphore release and WaitGroup completion even on panic

Benefits

• ✅ Partial extraction succeeds - continues processing remaining files after errors
• ✅ Better error visibility - errors logged to extractor output, not just build-tracer
• ✅ Graceful degradation - extract as much as possible instead of all-or-nothing
• ✅ Minimal code change - only 9 lines added, 3 modified

Testing

Tested on large codebase (700+ packages) with memory constraints. Before fix: extraction would fail silently on OOM. After fix: extraction continues and logs specific files that failed.

Impact

• Low risk - only changes error handling, doesn't affect extraction logic
• High value - makes extractor more robust for large/problematic codebases
• Backward compatible - successful extractions behave identically

Files Changed

• go/extractor/extractor.go: Updated extractPackage() error handling (lines 694-707)

[owen-mc]

Thank you for this contribution. I will try it out. Can you give any examples of projects which benefit from it?

[allsmog]

Thank you for this contribution. I will try it out. Can you give any examples of projects which benefit from it?

Hello, a multi module, massive scale OSS project would benefit from this. Good examples:
github.com/kubernetes/kubernetes or github.com/cockroachdb/cockroach. Don't use autobuild and try to trace the build with go-extractor on a fairly standard machine, let's say a moderately sized machine with 8GB RAM.

Observe that on old version, the old code would stop the entire scan. With this change, the tool will log the error for the problematic file, and move on, allowing analysis to continue despite OOM errors.

Find go.mod then run "go build -mod=vendor ./..." or -mod=mod depending on project's handling of vendor dir (as the codeql database build trace command). Monitor build tracer logs for evidence that extractor continues (or exits) depending on this fix being present.

[owen-mc]

Are you sure it matters if we use autobuild? I believe this code is run the same either way.

[allsmog]

Are you sure it matters if we use autobuild? I believe this code is run the same either way.

You're correct, the extractPackage() code path runs the same way regardless of whether autobuild is used. My suggestion to skip autobuild was about having more control over the test environment, not because the code behaves differently.

To clarify the reproduction steps:

1. It's easier to observe the behavior
   when you control the build command directly and can monitor
   logs in real-time. Autobuild adds abstraction that can make
   it harder to see what's happening.

2. How to reproduce the issue:

• Clone a large Go project (e.g., kubernetes/kubernetes or
  cockroachdb/cockroach)
• Run extraction on a memory-constrained environment (e.g.,
  8GB RAM container/VM)
• With the current code: when a file hits OOM, log.Fatal()
  terminates the entire extraction silently, you only see
  evidence in build-tracer logs, not extractor output
• With this fix: extraction logs the error for the
  problematic file and continues processing the remaining
  packages

3. The actual behavior change:

• Before: First OOM/error → entire extraction terminates
  (silent failure)
• After: OOM/error → logged, extraction continues with
  remaining files (graceful degradation)

cc @owen-mc

[owen-mc]

The code changes seem reasonable. My main question is whether the resulting databases are missing too much information to be usable or not. Are you able to share a database created with this patch where some files have OOMed? (Having the name of the files which OOMed would be helpful.)