Adding support for workflow context in condition callable

[droideronline]

adding support for workflow context inside the condition callable that we pass while adding an edge.

One use case where this might be useful is when I want to keep track of how many times my condition function has run. For example, if it runs 5 times, I would return False in the condition. This count could potentially be stored in the workflow context as shared state.

However, I can’t think of many other use cases right now, and I believe this request would require quite a bit of design consideration, hence bringing this up here for discussion.

If there are better ways to store the count, please let me know. Using contextvar could also work.

[droideronline]

cc - @ekzhu @moonbox3 @eavanvalkenburg

[nmccann]

I could see this being useful, I have a situation where the condition needs to be based on a a route (decided by an earlier router agent), but the “destination” executor doesn’t care about the route, it only cares about the original message. Because I don’t have access to the workflow context, I have my router executor output a tuple (of route + message) and then my condition checks the route. It’s not ideal though because I then need an intermediate executor whose only purpose is to ignore the route and only forward the message (since the next executor isn’t expecting a tuple). Having access to the context would avoid that.

That said, it has the downside of relying more on the context which can make it less clear how things relate to one another, it becomes this hidden shared state. Maybe a different approach would help with my situation, such as a “case map” function - which can both check the condition and change the format of the message all in one executor.