Cloud Run auto request after function deployed

[samuel-pp]

Related issues

[REQUIRED] Version info

node: 22

firebase-functions: 6.6.0

firebase-tools: 15.17.0

firebase-admin: 12.7.0

[REQUIRED] Test case

export const testRequest = functionsV2.https.onRequest(
    { cors: true },
    async (req, res) => {
        console.log('hello')
})

[REQUIRED] Steps to reproduce

deployed the 2Gen function

[REQUIRED] Expected behavior

the function deployed successful and log explorer is clean

[REQUIRED] Actual behavior

when the function is deployed, Log Explorer will show a GET request after that
It will trigger function error logic (because it cannot pass validation)

Were you able to successfully deploy your functions?

[samuel-pp]

[IzaakGough]

Hi @samuel-pp, thanks for raising this! We will review as soon as possible.

[IzaakGough]

Hi @samuel-pp, thanks for the screenshot, it actually explains a lot. This doesn't look like a bug in firebase-functions.

The GET request is a browser, not the SDK. The log shows a Chrome 149.0 user-agent loading / and then /favicon.ico, which is the normal pattern when a browser opens a page. So something opened your public *.run.app URL right after deploy. Usually that's you testing it, an uptime monitor, or a crawler finding the public URL (gen2 functions are public by default). It's not a Google health check, and cors: true has nothing to do with it.

The error is from your deployed function, not the SDK. The example you pasted only does console.log('hello'), so it can't produce those errors. They're coming from your actual function, which rejects the GET and calls functions.logger.error(...). The stack trace pointing at firebase-functions/lib/logger is normal: when you log an error with a plain string, the logger just adds a stack trace for you.

Quick fix: handle non-POST requests before validating, so these hits don't log as errors:

if (req.method !== 'POST') return res.status(204).end();

And if you don't want public traffic at all, deploy the function with authentication required.

I'll close this since it's working as expected, but happy to reopen if you find it's coming from the library itself.

[samuel-pp]

Hi @samuel-pp, thanks for the screenshot, it actually explains a lot. This doesn't look like a bug in firebase-functions.

The GET request is a browser, not the SDK. The log shows a Chrome 149.0 user-agent loading / and then /favicon.ico, which is the normal pattern when a browser opens a page. So something opened your public *.run.app URL right after deploy. Usually that's you testing it, an uptime monitor, or a crawler finding the public URL (gen2 functions are public by default). It's not a Google health check, and cors: true has nothing to do with it.

The error is from your deployed function, not the SDK. The example you pasted only does console.log('hello'), so it can't produce those errors. They're coming from your actual function, which rejects the GET and calls functions.logger.error(...). The stack trace pointing at firebase-functions/lib/logger is normal: when you log an error with a plain string, the logger just adds a stack trace for you.

Quick fix: handle non-POST requests before validating, so these hits don't log as errors:

if (req.method !== 'POST') return res.status(204).end();
And if you don't want public traffic at all, deploy the function with authentication required.

I'll close this since it's working as expected, but happy to reopen if you find it's coming from the library itself.

Sorry, the code snippet I provided was incorrect. It should be the onCall function.

functions
    .runWith({minInstances: 1})
    .https
    .onCall(async(data, context) => {
    console.log('hello')
})

functionsV2.https.onCall(
    (req, res) => {
        console.log('hello')
    }
)

There is no error log Invalid request, unable to process. in my code or third-party packages.
I can locate the relevant code within firebase-functions.

Issues with GET requests may indeed be caused by certain crawlers or scanners. But can I handle the req.method issue within my function code? It seems firebase-functions processes this before entering the handler, as there are no prints from my code logic in the Log Explorer.

[IzaakGough]

Hi @samuel-pp, you're exactly right on this.

For an onCall function, wrapOnCallHandler runs isValidRequest(req) before your handler ever gets called (common/providers/https.ts). A callable request has to be a POST with Content-Type: application/json and a data field, so when some crawler or scanner throws a plain GET at your public URL, that check fails right away. The SDK logs Request has invalid method. GET, then Invalid request, unable to process., and sends back a 400. Your code never runs, which is exactly why you don't see any of your own logs.

So to your question: no, you can't deal with req.method inside the onCall handler. That validation lives in the SDK wrapper ahead of your code, and there's currently no way to hook into it for callable functions.

A few things that might help:

• Nothing's actually broken here. Your real callable clients work fine. It's just noise from random unauthenticated GET traffic hitting the public URL.
• If the noise bugs you, the cleanest fix right now is a Cloud Logging exclusion filter on that log entry.
• And if you really want control over how different HTTP methods are handled, you'd want onRequest instead of onCall. Your handler runs for every request then, so you can respond to GET however you like. The tradeoff is you give up the callable protocol and its built-in auth handling.

That said, I think you've got a fair point that logging this at error severity for what's basically random internet traffic is noisier than it needs to be. I'll raise it with the team and see if we can dial that down.

Thanks again for the detailed report on this.

[samuel-pp]

Hi @samuel-pp, you're exactly right on this.

For an onCall function, wrapOnCallHandler runs isValidRequest(req) before your handler ever gets called (common/providers/https.ts). A callable request has to be a POST with Content-Type: application/json and a data field, so when some crawler or scanner throws a plain GET at your public URL, that check fails right away. The SDK logs Request has invalid method. GET, then Invalid request, unable to process., and sends back a 400. Your code never runs, which is exactly why you don't see any of your own logs.

So to your question: no, you can't deal with req.method inside the onCall handler. That validation lives in the SDK wrapper ahead of your code, and there's currently no way to hook into it for callable functions.

A few things that might help:

• Nothing's actually broken here. Your real callable clients work fine. It's just noise from random unauthenticated GET traffic hitting the public URL.
• If the noise bugs you, the cleanest fix right now is a Cloud Logging exclusion filter on that log entry.
• And if you really want control over how different HTTP methods are handled, you'd want onRequest instead of onCall. Your handler runs for every request then, so you can respond to GET however you like. The tradeoff is you give up the callable protocol and its built-in auth handling.

That said, I think you've got a fair point that logging this at error severity for what's basically random internet traffic is noisier than it needs to be. I'll raise it with the team and see if we can dial that down.

Thanks again for the detailed report on this.

Thank you very much and I look forward to your feedback.