-
Notifications
You must be signed in to change notification settings - Fork 4
Description
What would you like?
Currently, I have to use the Lambda client SDK to complete callbacks. It would be nice if users could do this through the context (required they have the right IAM permissions).
Possible Implementation
const [promise, callbackId] = await context.createCallback("approval"); // or use waitForCallback
await context.step(...)
const result = await promise;
await context.completeCallback("complete-approval", callbackId, { approved: true });Is this a breaking change?
No
Does this require an RFC?
No
Additional Context
Open Questions
-
Naming convention:
- SDK-style:
completeCallback/failCallback - Lambda API-style:
sendCallbackSuccess/sendCallbackFailure
- SDK-style:
-
Heartbeat inclusion: Should
sendCallbackHeartbeatbe part of the initial scope, or deferred? -
Alternative: Namespaced approach - Should this use a namespace like
context.callback.complete()similar tocontext.promise.all()? -
Overloads: Should we support both named and unnamed variants (with/without
nameparameter) like other context methods? -
Should these be durable operations? If called within a durable execution, should the callback completion be recorded in the execution history (for replay safety)?
-
Naming preference?
completeCallback/failCallbackvssendCallbackSuccess/sendCallbackFailure(matching the API names) -
Use case scope? Is this primarily for:
- Completing callbacks within the same durable function (self-completion)
- Completing callbacks from other durable functions
- Completing callbacks from non-durable code