Adapters should have an opportunity to handle results

[heyitsaamir]

Problem Statement

I'm not sure if the title of this issue is the best, but let me describe the issue first.

In Teams, "actions" are not async. So if you have a modal you want to open, you get a request, and you respond to it with the parameters of the modal, and then it opens. This differs from Slack, where you can cache the parameters for modal opening, and then imparatively trigger the modal to open asynchronously.

With the current Chat interface, processAction returns void. So when the handler gets an open-modal event from Teams, it calls chat.processAction, but it can't do anything with the result of that. The expectation is that chat will call openModal which then imparatively should open the modal.

Proposed Solution

There's a few potential ways to handle this imo:

1. Allow processAction to return the results of actions. So processAction could return the result of openModal, and then it is the responsibility of the adapter to handle that (cache it, send it imparatively, return it immediately. It's on the adapter).
2. Make processAction awaitable. If processAction is awaitable, then openModal can resolve the promise once it's called. This option seems fragile to me, but it's an option.
3. Pass openModal inline as part of processAction. Then in the openModal interceptor, the options.openModal is called first (if provided). The adapter can listen to this function resolving (maybe via a Promise.race).

processAction(event, {
    waitUntil,
    onOpenModal: async (modal) => {
      // adapter-specific handling right here
      // Teams: stash it for the invoke response
      // Slack: call views.open
      return { viewId: '...' };
    }
  });

Alternatives Considered

No response

Use Case

Here is a more full-example of the 3rd option:


 app.on('dialog.open', async (ctx) => {
    const activity = ctx.activity;
    const threadId = this.encodeThreadId({
      conversationId: activity.conversation?.id || "",
      serviceUrl: activity.serviceUrl || "",
    });

    // Promise that resolves when the handler calls openModal
    let resolveModal: (modal: ModalElement) => void;
    const modalPromise = new Promise<ModalElement>((resolve) => {
      resolveModal = resolve;
    });
    let modalWasOpened = false;

    const actionEvent = {
      actionId: activity.value?.data?.actionId || "dialog.open",
      value: activity.value?.data,
      triggerId: activity.id,
      user: { /* ... from activity */ },
      messageId: activity.replyToId || activity.id || "",
      threadId,
      adapter: this,
      raw: activity,
    };

    // processAction is still fire-and-forget, but the interceptor
    // captures the modal synchronously during handler execution
    this.chat.processAction(actionEvent, {
      waitUntil: (p) => p, // no-op, we handle timing ourselves
      onOpenModal: async (modal, contextId) => {
        modalWasOpened = true;
        resolveModal(modal);
        return { viewId: contextId };
      },
    });

    // Wait for the handler to call openModal (or timeout)
    const modal = await Promise.race([
      modalPromise,
      new Promise<null>((resolve) => setTimeout(() => resolve(null), 5000)),
    ]);

    if (modal && modalWasOpened) {
      const card = modalElementToAdaptiveCard(modal);
      return {
        task: {
          type: 'continue',
          value: {
            title: modal.title || 'Dialog',
            card: { contentType: 'application/vnd.microsoft.card.adaptive', content: card },
          },
        },
      };
    }

    // Handler didn't open a modal — close silently
    return { status: 200 };
  });

Priority

None

Contribution

• I am willing to help implement this feature

Additional Context

No response

[bensabic]

Thanks, this makes sense.

I traced the current flow and agree there's an architectural gap here, especially for Teams. Right now processAction() is intentionally fire-and-forget, and event.openModal() assumes the adapter can open the modal imperatively later. That maps cleanly to Slack, but not to Teams/task-module style flows where the modal payload needs to be returned inline with the action response.

Of the options above, I think the least disruptive path is an explicit interception hook for openModal during action processing rather than making processAction() itself return a result. Returning from processAction() is awkward because action handlers don't return anything today and multiple handlers can run for the same action. Making it awaitable has similar ambiguity and also couples completion to whether a modal was opened.

So I'd lean toward something like:

chat.processAction(actionEvent, {
  waitUntil,
  onOpenModal: async (modal, contextId) => {
    // adapter-specific handling
  },
});

Then event.openModal() can call onOpenModal when present, and fall back to adapter.openModal() otherwise. That would let adapters like Teams capture the modal synchronously for the invoke response without changing the default fire-and-forget behavior for Slack and the other adapters.

[heyitsaamir]

Thanks, this makes sense.

I traced the current flow and agree there's an architectural gap here, especially for Teams. Right now processAction() is intentionally fire-and-forget, and event.openModal() assumes the adapter can open the modal imperatively later. That maps cleanly to Slack, but not to Teams/task-module style flows where the modal payload needs to be returned inline with the action response.

Of the options above, I think the least disruptive path is an explicit interception hook for openModal during action processing rather than making processAction() itself return a result. Returning from processAction() is awkward because action handlers don't return anything today and multiple handlers can run for the same action. Making it awaitable has similar ambiguity and also couples completion to whether a modal was opened.

So I'd lean toward something like:

chat.processAction(actionEvent, {
waitUntil,
onOpenModal: async (modal, contextId) => {
// adapter-specific handling
},
});
Then event.openModal() can call onOpenModal when present, and fall back to adapter.openModal() otherwise. That would let adapters like Teams capture the modal synchronously for the invoke response without changing the default fire-and-forget behavior for Slack and the other adapters.

Makes sense -- curious, what about the processAction function returning a void | Promise<void>? This way we can avoid having the Promise.race. Handlers can fire-and-forget if they want (like they do right now). Or they can await the completion of processAction. Thoughts?

[bensabic]

I think returning a promise makes sense, but I’d make it Promise<void> rather than void | Promise<void>. If callers want fire-and-forget, they can just ignore the returned promise, so the union doesn’t buy much and makes the API a bit fuzzier.

That said, I don’t think awaitability fully replaces the hook. It gives the adapter a synchronization point, but it still doesn’t surface the modal payload/context by itself, and it waits for the full handler chain rather than the first openModal() call.

That matters for Teams because the inline response wants to unblock as soon as the modal is captured, not after any unrelated async work finishes. For example, if a handler does await event.openModal(...) and then some follow-up async work, or if multiple matching handlers run, await processAction() would hold the response open longer than necessary.

So I’d be in favor of:

1. changing processAction() to return Promise<void>
2. still adding onOpenModal so the adapter can capture the modal/context
3. documenting that inline-response platforms need openModal() to happen before long-running work

If we only do one of those, I’d still prioritize the hook, because that’s the part that solves the actual result-capture problem.

[heyitsaamir]

I think returning a promise makes sense, but I’d make it Promise<void> rather than void | Promise<void>. If callers want fire-and-forget, they can just ignore the returned promise, so the union doesn’t buy much and makes the API a bit fuzzier.

That said, I don’t think awaitability fully replaces the hook. It gives the adapter a synchronization point, but it still doesn’t surface the modal payload/context by itself, and it waits for the full handler chain rather than the first openModal() call.

That matters for Teams because the inline response wants to unblock as soon as the modal is captured, not after any unrelated async work finishes. For example, if a handler does await event.openModal(...) and then some follow-up async work, or if multiple matching handlers run, await processAction() would hold the response open longer than necessary.

So I’d be in favor of:

1. changing processAction() to return Promise<void>
2. still adding onOpenModal so the adapter can capture the modal/context
3. documenting that inline-response platforms need openModal() to happen before long-running work

If we only do one of those, I’d still prioritize the hook, because that’s the part that solves the actual result-capture problem.

That's fair, and I agree. Let me stub this out and see what the code looks like for Teams

[bensabic]

Thanks Aamir!

[heyitsaamir]

@bensabic #311 this guy came up while implementing this feature. If you get a chance, mind reviewing it?

[bensabic]

Hey @heyitsaamir! Yes, sorry for the delay, planning to review it today!

Quick Q: can you send me your email on X/Twitter or LinkedIn? Would love to add you to our new external Slack channel for Chat SDK adapter contributors. It'll allow folks like yourself to have a direct line to our team.

[heyitsaamir]

Yes @bensabic! Try me on Linked In (Aamir Jawaid), or bsky.