Open hossam-nasr opened 1 year ago
There are 3 options I can see here:
Durable APIs live under a df
object, and OrchestrationContext
/EntityContext
types extend InvocationContext
Durable contexts (OrchestrationContext
/EntityContext
) still extend InvocationContext
, but the Durable APIs live directly on the context object, rather than under one df
object.
Durable contexts contain the Durable APIs directly, but then add an invocationContext
parameter that contains the InvocationContext
object. In that way, Durable contexts would behave similarly to execution hook contexts.
@hossam-nasr: From my understanding, we decided to keep this as-is for now. Is that correct?
@davidmrdavid Yes, I believe we decided to skip this for preview. Removed the preview label
Currently, all orchestration APIs are provided under a
df
parameter inside theContext
object, e.g.,context.df.callActivity()
,context.df.callSubOrchestration()
,context.df.currentUtcDateTime
, etc.Since all these durable APIs are a lot more relevant to the user than the other metadata (coming from Azure Functions directly) present in the context object, this issue is to explore whether we should provide the APIs directly in the Context object rather than nested inside a
df
property. We could also define our own type of orchestration context, picking only the relevant elements from the Functions context, instead of extending it.