When multiple print() statements in an aspect have the same contents, only the first one has any effect and the rest are de-duplicated away.
@aehlig
@sergiocampama thanks for the offline pointer -- this is almost certainly from --experimental_ui_deduplicate.
A while back we changed print() statements to emit "DEBUG" events, regardless of what file the print() appeared in. This was so that prints would no longer get filtered if they originated in a different package or in an aspect that propagated to a different package -- old behavior that users found confusing. Our reasoning was that print() should only ever be used for debugging, and not appear in production code unless guarded by some kind of "if debug" guard.
The fact that they're being filtered to de-spamify the console means that we're conflicted on what the purpose of print() is. We need a consistent story for whether print() is for debugging, and if it is, we need to exempt DEBUG events from ui deduplication.
As of this moment, --experimental_ui_deduplicate is disabled by default. It might be a feature that is not useful in all cases, but I fail to see where this is a bug.
Proposal: Exempt DEBUG events from deduplication, but make DEBUG events not shown by default. That way you can't abuse print() for informational (non-debugging) purposes, and there's no need to rate-limit it.
The bug is that
1) print() is ostensibly for debugging
2) when this feature is enabled, this use case is partially thwarted
The fact that the feature isn't (yet) enabled by default in Bazel mitigates the impact but doesn't change the fact that this contradiction exists. We need to either explicitly decide that print() is not just for debugging, or else exempt it from this filtering.
This feature (message deduplication) has caused confusion in the past to the point where some callers implemented workarounds (as explained in this bug) and we had to disable it a year ago within Google (and also in Bazel). Looking at Google-internal usage, nobody seems to be using this any more.
This feature comes with significant complexity and attempts to parse stdout/stderr as text, which arguably we should not be doing because some messages may be binary.
Therefore, I propose that we simply delete --experimental_ui_deduplicate.
Most helpful comment
This feature (message deduplication) has caused confusion in the past to the point where some callers implemented workarounds (as explained in this bug) and we had to disable it a year ago within Google (and also in Bazel). Looking at Google-internal usage, nobody seems to be using this any more.
This feature comes with significant complexity and attempts to parse stdout/stderr as text, which arguably we should not be doing because some messages may be binary.
Therefore, I propose that we simply delete
--experimental_ui_deduplicate.