"target" struck me as odd since it's an info rather than a target. then my second thought was that target would be "where it's stored" rather than "what's being called."
Maybe callee_info or something?

Like you said, target might not be the best name here. It implies where something should be stored, which is what the information is hinting at. It's trying to say "use this information for storing the payload in a structured manner".

Implementation wise, the target could be the current context or the other size of the serialization boundary. So calling it caller or callee would be wrong in a handful of scenarios. For example, if this was invoke for the result of a completing workflow, it's the "caller" information if it's the top-level workflow but is the "callee" information if the workflow has a parent. Because we want to store it (in terms of S3 terminology) the key prefix for the object that needs it for replay and for lifecycle management. So the API is opinionated as to what information should be used for storing in some kind of hierarchy.

Maybe:

• context_info? Feels generic.
• hierarchy_info? Why is the API telling me about a hierarchy when there isn't an obvious prescription of how to generate the hierarchy? Maybe the API should be offering a visitor for prescriptive ordering and layering of the information.

separate caller_info field ? Feels like glossing over this distinction between source and target or caller and callee could result in bugs. Would rather callsites explicitly say what they want to refer to.

During code review, we talked about the idea of providing both "caller" and "callee" information and felt that it was ambiguous as to how a driver author was supposed to use them, because you don't always store in the callee context.

When talking in terms of the S3 driver, there was an overall pattern of we always want to store the information in a key space that best suits itself for replay and for lifecycle management. That mostly meant the "target workflow" (e.g. child workflow, external signal, CaN, completing workflow that does have a parent) but is sometimes the the current workflow" (e.g. workflow activities, completing workflow that doesn't have a parent); sometimes it is the "current activity" (completing standalone activity) but is sometimes the "target activity" (client starts a standalone activity).

Just providing "caller" and "callee" information isn't enough; you also need to know standalone vs workflow activity. Maybe that's all the extra was needed but the algorithm is not easy to implement.

We felt that this determination would be the same across drivers, if they cared to store payloads in a contextual hierarchy. So it was built into the external storage layer rather than just a concern driver authors had to think about.