search

pantsbuild / pants

The Pants Build System
https://www.pantsbuild.org
Apache License 2.0
3.3k stars 632 forks source link

BSP: (Re)consider sending all workunits as task notifications #15426

Open stuhood opened 2 years ago

stuhood commented 2 years ago

The BSP task model is shaped like tracing spans, and consequently matches our workunit model fairly well (span_id ~= task_id, and tasks have parents).

To stream workunits to a BSP client, we would install a StreamingWorkunitHandler around a BSPConnection which used a BSPContext to send workunits as TaskNotifications to the client. In general, the span_id would be directly used as the task_id (including for parent relationships), but one @rule at the top of each relevant request would want to install an EngineAwareReturnType which linked the origin_id of the request as the parent of its workunit instead.

The largest challenge with doing this (and thus why it wasn't the obvious choice for #14885) is that a large amount of workunit filtering would need to happen. Currently, the --dynamic-ui renders all DEBUG level workunits to show liveness... but this would result in sending dependency extraction, etc to the client. Likewise, rendering all INFO level workunits would be too quiet. In particular: it would not render individual compiles.

stuhood commented 2 years ago

Mm, an annoyance in the model of #15415 is that BSPCompileRequest/BSPClasspathEntryRequest containing an origin_id/task_id means that every request has a new identity, and will thus re-render all compile notifications (even if nothing has changed).