Support Azure Functions v4 Model for webhookCallback

[mildronize]

Background

First of all, I’d like to thank the team behind grammy for creating such an amazing Telegram framework! I’ve enjoyed working with it, especially on my open-source bot using Cloudflare Workers.

Recently, I tried to use the webhookCallback feature with Azure Functions v4 (the latest official version of the Node.js runtime).

However, I encountered an issue where Cloudflare Workers did not fully support Node.js APIs (details here). As a result, I returned to Azure Functions for deployment. After reviewing the webhookCallback interface, I found that it works well with the Azure Functions v3 model (as tested with the following code):

import { webhookCallback } from 'grammy';
await webhookCallback(bot, "azure")(request, context);

Environment

• Runtime: Node.js 20
• grammy Version: 1.34.0

Issue Summary

1. The grammy documentation does not specify which versions of Azure Functions are supported. Based on my tests, it seems only Azure Functions v3 is compatible, and Azure Functions v4 is not yet supported.
2. To assist others, I created a template for grammy with Azure Functions v3 using Nammatham v1, to help developers get started more easily.
3. This is not a complaint! The work you’ve done is fantastic, and if I have some free time, I’d be happy to contribute to Azure Functions v4 support. If the maintainers can guide me on where to start, I’d greatly appreciate it.

Thank you for taking the time to read this issue, and keep up the great work!

[KnorpelSenf]

Hi! Thanks for the kind words!

Re-reading the code, I am actually surprised that grammY 1.34 works with v3. Isn't v3 supposed to have the request as the second argument?

grammY/src/convenience/frameworks.ts

Lines 276 to 291 in b04bfee

	/** Azure Functions */
	const azure: AzureAdapter = (request, context) => ({
	update: Promise.resolve(request.body as Update),
	header: context.res?.headers?.[SECRET_HEADER],
	end: () => (context.res = {
	status: 200,
	body: "",
	}),
	respond: (json) => {
	context.res?.set?.("Content-Type", "application/json");
	context.res?.send?.(json);
	},
	unauthorized: () => {
	context.res?.send?.(401, WRONG_TOKEN_ERROR);
	},
	});

It looks like the order of context and request is wrong.

That being said, we clearly need a new adapter to support v4.

I opened #738 which should fix both issues. You can install it from GitHub via

npm install github:grammyjs/grammY#support-azure-v4

Could you test the following two cases and confirm that they work?

• Azure Functions v3 with webhookCallback(bot, "azure")
• Azure Functions v4 with webhookCallback(bot, "azure-v4")

[KnorpelSenf]

import { webhookCallback } from 'grammy';
await webhookCallback(bot, "azure")(request, context);

Oh now I see it. You basically added a workaround that fixes the issue in grammY. That's why it did not crash on your end. This was never supposed to be necessary.

[mildronize]

@KnorpelSenf Thank you for your explanation. I now understand your points. In the current version of grammY (1.3.4), using the original Azure Functions v3 model might cause issues due to incorrect argument order.

Somehow, with my framework, Nammatham, this can be resolved as it manually pass the arguments. For example:

import { webhookCallback } from 'grammy';
await webhookCallback(bot, "azure")(request, context);

Thank you so much for addressing the issue so quickly! I'm pleasantly surprised and excited about this progress. I'll now prepare a repository to test both the v3 and v4 adapters and will share the results with you once they are ready.

[mildronize]

@KnorpelSenf For v3 result test, I've successfully run grammY on locally, but I've found that the type of Context in @azure/functions@v3.5.1 not compatible with your provided in the library Context.

Here is the code for v3: https://github.com/mildronize/grammy-azure-functions-test/tree/main/func-v3

the type error is here:

the full error:

Argument of type 'Context' is not assignable to parameter of type '{ res?: { status: number; body: string; headers?: Record<string, string>; set?: (key: string, value: string) => void; send?: { (body: unknown): void; (status: number, body: unknown): void; }; }; }'.
  Types of property 'res' are incompatible.
    Type '{ [key: string]: any; }' is missing the following properties from type '{ status: number; body: string; headers?: Record<string, string>; set?: (key: string, value: string) => void; send?: { (body: unknown): void; (status: number, body: unknown): void; }; }': status, body

the code that error found

const telegramBot: AzureFunction = async function (
  context: Context,
  request: HttpRequest,
): Promise<void> {
  await webhookCallback(bot, "azure")(context, request);
};

Type of Azure/Functions Context

As you can see in the Official Azure Functions Code, https://github.com/Azure/azure-functions-nodejs-library/blob/v3.5.1/types/Context.d.ts#L11-L71, you will see the context is not match as the error occurs.

And your context will be https://github.com/grammyjs/grammY/blob/support-azure-v4/src/convenience/frameworks.ts#L82-L94

Solution

I've created the PR that fix that of your Context: #739

and the result as show below

[KnorpelSenf]

Epic, thank you!

[KnorpelSenf]

@mildronize it's merged, can you confirm that the pull request #738 introduces the right changes now?

[mildronize]

@KnorpelSenf let's me test it on azure func v4
And deploy on azure already, I'll let you know later

[mildronize]

@KnorpelSenf

Problem in Type v4

I've founded that type is incorrect in Azure Functions v4 (@azure/functions@4.6.0), due the original type of

• HttpRequest: https://github.com/Azure/azure-functions-nodejs-library/blob/v4.6.0/types/http.d.ts#L76-L154
• InvocationContext: https://github.com/Azure/azure-functions-nodejs-library/blob/v4.6.0/types/InvocationContext.d.ts#L17-L101

After i've fixed typed,

I can run them smoothly, I've tested locally and already deployed on Azure for Both v3, V4

Test Result for v3

Test Result for v4

Solution

Due to Azure Functions v4 type of InvocationContext and HttpRequest is incorrect, I've fixed in the PR #742

After merge this PR, I think everything work fine both v3 and v4.