Summary
rtk can swallow or misclassify real Go compile/vet errors. In our project this caused rtk go ... output to report
misleading summaries such as:
No tests foundNo issues found2 errors
These summaries did not reflect the actual Go compiler/vet failure. The only reliable way we found to see the real
error was to bypass filtering with rtk proxy.
Version
rtk --version
# rtk 0.42.0
Reproduction / Diagnosis
Running normal filtered Go commands through rtk hides the actionable compiler errors.
The real errors are visible with:
rtk proxy go vet ./internal/workorder/biz/ 2>&1 | grep -iE "undefined|cannot|cycle"
Without rtk proxy, the filtered output can incorrectly summarize the run as successful or unrelated.
One confusing example: go-m1cpu may print 2 errors, but those are clang/CGO warnings and the build exits with 0;
meanwhile the actual Go errors such as undefined, cannot, or import cycle can be filtered away.
Expected Behavior
rtk go / Go-related filters should preserve real Go compile/vet errors, especially diagnostics containing patterns
like:
- undefined
- cannot
- import cycle
- package/type/function resolution failures
If filtering is uncertain, it should prefer showing the raw Go diagnostic rather than summarizing as No issues
found / No tests found.
Actual Behavior
The filtered output can hide the real compiler/vet diagnostics and emit misleading summaries, causing agents/users to
debug the wrong issue.
Impact
This is high impact for AI-agent workflows because the agent trusts the filtered terminal output. When compiler
errors are hidden, the agent may conclude the build/test/vet pass is clean or chase unrelated CGO warnings.
Workaround
Use raw proxy mode:
rtk proxy go vet ./internal/workorder/biz/ 2>&1 | grep -iE "undefined|cannot|cycle"
But this defeats the purpose of using rtk go for safe summarized Go diagnostics.
Summary
rtkcan swallow or misclassify real Go compile/vet errors. In our project this causedrtk go ...output to reportmisleading summaries such as:
No tests foundNo issues found2 errorsThese summaries did not reflect the actual Go compiler/vet failure. The only reliable way we found to see the real
error was to bypass filtering with
rtk proxy.Version
rtk --version # rtk 0.42.0Reproduction / Diagnosis
Running normal filtered Go commands through rtk hides the actionable compiler errors.
The real errors are visible with:
rtk proxy go vet ./internal/workorder/biz/ 2>&1 | grep -iE "undefined|cannot|cycle"
Without rtk proxy, the filtered output can incorrectly summarize the run as successful or unrelated.
One confusing example: go-m1cpu may print 2 errors, but those are clang/CGO warnings and the build exits with 0;
meanwhile the actual Go errors such as undefined, cannot, or import cycle can be filtered away.
Expected Behavior
rtk go / Go-related filters should preserve real Go compile/vet errors, especially diagnostics containing patterns
like:
If filtering is uncertain, it should prefer showing the raw Go diagnostic rather than summarizing as No issues
found / No tests found.
Actual Behavior
The filtered output can hide the real compiler/vet diagnostics and emit misleading summaries, causing agents/users to
debug the wrong issue.
Impact
This is high impact for AI-agent workflows because the agent trusts the filtered terminal output. When compiler
errors are hidden, the agent may conclude the build/test/vet pass is clean or chase unrelated CGO warnings.
Workaround
Use raw proxy mode:
rtk proxy go vet ./internal/workorder/biz/ 2>&1 | grep -iE "undefined|cannot|cycle"
But this defeats the purpose of using rtk go for safe summarized Go diagnostics.