@mikgross I am seeing similar issues since upgrading my firebase-functions version.

Did you manage to resolve this?

similar issue here

Hey there, this is an issue we'll need to look at. functions.http.Request is actually an express.Request, but we redefined what it was to add on some additional type info (e.g. that body was now JSON due to bodyparser). We can look into fixing this (though there might be some reverse compatibility concerns). For now, though, if you forcibly cast it to express.Request it should work.

    corsCheck(req as any as express.Request, res as any as express.Response, async () => {
        res.status(200).send('Nice');
    }

Thanks for the workaround. Will definitly try it!

I dove into the code and think I may see the bug. We have

export interface Request extends express.Request {
  rawBody: Buffer;
});

which seems right. Except that express.Request is a generic interface. By extending Request we're extending a type with fixed defaults, which may be causing the issues you see. I'll dive in more when I have a chance.

Believe we have the same issue, is this still a known problem?

Yes. It's a low priority since a cast does the trick. Internal bug #209905562

Yes. It's a low priority since a cast does the trick. Internal bug #209905562

But also super annoying for someone trying to figure out why types are all over the place until finally landing on this thread.

Not only that you're bypassing type safety by doing so .. especially if something is changed firebase later on (which seems to be common with Google)

... no wonder all the examples are in javascript and not typescript

To completely bypass type safety as suggested above:

 // eslint-disable-next-line @typescript-eslint/ban-ts-comment
 // @ts-ignore
onRequest(async (request: any, response: any) => {
  request = request as Request;
  response = response as Response;
...
}