← Challenges

Repository · challenges

Kompile reports successful build-rule notifications as unhandled errors during focused tests

View on GitHub ↗

Kompile reports successful build-rule notifications as unhandled errors during focused tests

Reported (UTC): 2026-07-14 04:11

Kompile reports successful build-rule notifications as unhandled errors during focused tests

What was being attempted: Run PATH="$HOME/bin:$PATH" scripts/test.bash --test testGitSyncReconnectsAfterProxyFailure in HandoffServiceServer to capture the required red TDD baseline.

What went wrong: Before the actual expected assertion failure, kompile printed many repeated blocks beginning '[ERROR] Unhandled effect: kompile.BuildRuleExecutedEffect' with stack traces through kompile.cli.CliKt.handleCliNotificationEffect, even though each payload said 'build rule executed: handoff.serviceserver.buildSkinnyJar() (succeeded in 0ms)' or another successful build rule. The focused run eventually produced the real assertion failure, but it was buried beneath thousands of misleading error lines.

Impact: Successful build activity looks like infrastructure failure, dramatically obscures the actionable test failure, inflates logs, and makes automated or human diagnosis risky because '[ERROR]' no longer distinguishes a real failure.

Workaround used: Ignore the repeated BuildRuleExecutedEffect blocks and locate the final FAILED test line and stack trace; no retry or test weakening was used.

Suggested durable fix: In kompile's CLI notification-effect handling, install a specific handler for BuildRuleExecutedEffect and render successful executions as concise informational output (or suppress them), reserving '[ERROR]' and stack traces for genuinely unhandled failure effects. Add an end-to-end CLI regression test that runs a test with a build-rule artifact and asserts no '[ERROR] Unhandled effect' output for successful rule execution.


Production verification — 2026-07-17

Status: STILL EXISTS. Two new same-day reports on current main document retained Kompile scratchspace masking source changes, so the stale-cache/source-selection mechanism has not been retired. The system Coursier launcher itself now works, narrowing older mixed reports away from the former architecture problem.

This record was retained because its underlying mechanism remains observable or its durable fix is still open; historical incident details above remain useful reproduction evidence.