Skip to content

Conversation

@sluongng
Copy link
Contributor

When a user abort a build, our current error card would show:

Build aborted

ERROR: user interrupted
ERROR: //foo:bar: user interrupted
ERROR: //baz/baa:fou: user interrupted
...

which can be noisy, especially when
experimental_cancel_concurrent_tests was used when multiple test
executions were cancelled in parallel.

Reduce the noise by ignoring the aborted events with USER_INTERRUPTED
reason. This means that we should only show

Build aborted

ERROR: user interrupted

from the Finished event in this card.

@sluongng sluongng requested review from bduffany and siggisim October 16, 2025 09:25
@sluongng sluongng force-pushed the sluongng/denoise-invocation-error-card branch 2 times, most recently from 18750eb to 9eda895 Compare October 16, 2025 12:40
When a user abort a build, our current error card would show:

```
Build aborted

ERROR: user interrupted
ERROR: //foo:bar: user interrupted
ERROR: //baz/baa:fou: user interrupted
...
```

which can be noisy, especially when
`experimental_cancel_concurrent_tests` was used when multiple test
executions were cancelled in parallel.

Reduce the noise by capturing only the first Aborted event with
USER_INTERRUPTED reason. Also include TargetCompleted label to the
error log. This means that we should only show

```
Build aborted

ERROR: //first/canceled:target: user interrupted
```

from the targetCompleted event in this card.
@sluongng sluongng force-pushed the sluongng/denoise-invocation-error-card branch from 9eda895 to cc5bdcc Compare October 16, 2025 12:50
@sluongng sluongng marked this pull request as ready for review October 21, 2025 08:47
Comment on lines +192 to +193
// Capture the very first USER_INTERRUPTED aborted event and
// ignore other USER_INTERRUPTED events to reduce noise in the UI.
Copy link
Member

@bduffany bduffany Oct 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we simplify this / make it less stateful by just ignoring the target-specific interrupted events? e.g. looking at the example from the PR description

ERROR: user interrupted
ERROR: //foo:bar: user interrupted
ERROR: //baz/baa:fou: user interrupted

would it make sense to just ignore events where the target label is nonempty and the abort reason is USER_INTERRUPTED?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants