Erik Sipsma

> Just checking that whatever option we choose, it’s forward-compatible (as far as we know) with extensions and the composition model that they will enable? Yeah obviously it's fuzzy but...

> is there an option 3 where my util could in the future be mapped to its own graphql resolver, and added to the GraphQL schema as a full-blown step...

> In the case where job is released and it releases all the `state` except the one that was `targetState` for another job's merged edge, is it possible that this...

@tonistiigi Pushed a fix for that: https://github.com/moby/buildkit/pull/4887/commits/ffdbd863b34ad0c6505949ebbda5e61722c939ad I realized in practice I'm not sure how that case could actually get hit since it would require that one edge is mergeable...

> I might be misunderstanding the recursive part of this here - but essentially we're taking all ancestors of a node and adding the job to each state here? >...

> > if we don't then you can get into a situation where those vertices execute and no longer have any sessions attached and thus are guaranteed to fail... >...

> Any estimation how many merged edges would behave like this. Most of the cases come from multiple local sources tracking the same files. So these do have sessions associated...

> > "unmerge" and use a different src edge with a job still around? > > I don't think we would need "full unmerge". The possible issues could come `sharedOp`...

ping @tonistiigi on the questions asked here https://github.com/moby/buildkit/pull/4887#issuecomment-2086091772

One quick update, it does appear that some form of the more complex change (where we add jobs to all ancestor states) is needed due to the fact that `walkProvenance`...