Michael Edgar

I have a prototype of this here: https://bazel-review.googlesource.com/c/bazel/+/231672. No OSS tests yet but it does appear to work.

Well, the whole point was to have all the patches under one repository. It's not as easy on github to browse through all of an organization's repos, and one repository...

We definitely aim to not retain events for longer than necessary -- holding onto them would be a proper memory leak. We do currently retain all of the `BuildEventId` objects...

Any heap dumps would be helpful! The progress events are actually only 40 bytes on the heap. (The empty UnknownFieldSet is a singleton object and shared across all protobufs with...

A challenge with changing the current algorithm in BuildEventStreamer is that it accounts for events arriving out-of-order. In particular it allows events to declare that they must be delivered *after*...

> Thanks for looking into this! > > > These events have IDs that are just monotonically increasing integers > > For what it's worth, our application does not use...

Re-posting from an email conversation: > Having worked on the effort that first brought these APIs into public use, my perspective is: it would be great to have other build...

I am sending out for review an internal change to this API that will add the new `BuildTool.build_tool_event` field. It will be a while before Bazel uses this by default,...

Interesting point! I added this in commit 3ebfe2450b66467b7c91b5da0f289b50686cb9bc to address a straightforward means to crash the build tool during the analysis phase. The "must be a global variable" enforcement happens...

This looks good to me. I would rename the new class (eg. `SendSerializedBuildEventCommand`) but the logic seems sound. Unfortunately it doesn't merge cleanly at this point, so I'll have to...