```in practice I guess the first rule to trigger a...
# development
d
Copy code
in practice I guess the first rule to trigger a rule would be the acting parent of that triggered rule
I think this is how we want to view parent-child relation for v2, but I @average-vr-56795 and @witty-crayon-22786 may correct me or give more context
w
yea, i believe that that's how we've been looking at it.
it will be accurate "most of the time"
a
Currently all rules are children of a single workunit, and the remoting and store ones are children of the rule that triggered them
w
the reason i keep pointing to https://github.com/pantsbuild/pants/issues/7907 though, is that we will almost certainly not want to track all nodes. which means the current workunit code is not where we want it to be. cc @happy-kitchen-89482
would look at that issue a bit longer, and then work backwards to where the workunits should be recorded. and then look at parents
a
+1 🙂
h
Yes, that's exactly what I'm looking at right now - which nodes to track.
w
h
Am I right that currently the zipkin traces get posted in bulk at the end of the pants run? Does zipkin generally support live updates of ongoing spans?
w
Does zipkin generally support live updates of ongoing spans?
yes: that's more conventional. people use message buses and etc
twitter internally uses Scribe, in general... but the upstream project deprecated that, and i don't know what they recommend now.
h
But right now Pants does not do so, and instead posts in bulk? That is my understanding of the code, but I am new to Rust so...
w
correct.
the bulk posting happens on the python side, using pyzipkin.
Is pushing data to the python side?
NM I'm figuring out the extern stuff now, so I think I get it
w
re: push vs pull: mostly python calls rust (via
engine/engine_cffi/src/lib.rs
), and rust calls python for only very basic primitives (via
engine/src/externs.rs
)