firebase-functions: Deployed functions fails to read runtime config on Node 10

Hey everyone, thanks for the patience. We’ve discovered the root of the problem, and it’s due to a rollout of build packs for the Node 10 runtime. (That’s why only some functions experience the issue, and not others) We’ve asked the team to start ramping down the rollout, so in the next few hours, the feature will be fully ramped down. The SDK fix has been made in https://github.com/firebase/firebase-functions/pull/634. In the meanwhile, the quickest way to get your functions to work again is to revert to Node 8 (see my comment above). Thanks again for bearing with us!

Thanks for the report everyone, for now, please revert to using Node 8. We will continue to investigate and make a fix to Node 10.

To revert to Node 8, edit the “engines” field in package.json:

  "engines": {
    "node": "8"
  }

I think something has changed in the directory structure that is deployed to / inside GCF. In our case the code was unable to find the .runtimeconfig.json that is automatically packaged with the code. We are currently testing the following workaround which seems to fix it in our environment.

import { readFileSync } from 'fs';
import { resolve } from 'path';
try {
    process.env.CLOUD_RUNTIME_CONFIG = process.env.CLOUD_RUNTIME_CONFIG
        || readFileSync(resolve(__dirname, '.runtimeconfig.json'), 'utf8');
} catch (e) {
    console.log('setting CLOUD_RUNTIME_CONFIG failed', e);
}

Note that .runtimeconfig.json is in the root of the deployment, so make sure to get the relative path right (in our case, the file that includes the workaround (our index.ts) happens to be in the root as well).

Also, the workaround needs to be executed before any function is registered and probably before the import of firebase-functions.

@zerobytes Have you actually bothered to read the previous comment that clearly states the problem has been discovered and will be rolled out soon? Stop flashing your CTO badge and use your brains, please.

This is pretty frustrating as we had the staging CI deploy and run fine however the deploy to production doesn’t have the config data (because it was deployed after the bug was released).

There’s also no way to rollback and fortunately we realised (after a couple hours of debugging) that the issue was specific to using the region() command which meant we could at least re-deploy our functions in favour of https and firebase firebase-function declarations. Our functions are now deployed in a completely different part of the world and the performance is taking a clear hit.

The fact that this issue wasn’t caught by your internal CI systems, as well as the fact that there’s no way for the end user to recover and rollback from the issue is embarrassing.

Please rectify this with high priority.

Hi everyone, thanks again for the patience. The fix has been released in v3.4.0. Please update your package.json to point to this latest version, so that when build packs get re-rolled out, your functions will continue to work.

@FredyC I hope you’re not into management of anything, as in your opinion i should not use my customer status to get at least the minimum i deserve.

If you’re happy with the 3 days it took to solve the issue, that’s up to you, but me and my business as many others who certainly complained through other channels do not take those 3 days as something even near to the expected response to a business solution provider, such as Firebase.

• Also, being a CTO clearly states that i use what i have, probably more than you do.

Now, to the dev team, who’s faraway from being held responsible for the bad customer care, i appreciate the effort to solve the issue and thank for being the only part of google who actually shows some respect with customers.

@jassmith this has been fixed in v3.5.0. Thanks for reporting!

We’re also experiencing this issue

I think you have a package-lock.json that’s causing @types/express 4.17.2 to be installed. Our package.json has “@types/express”: “^4.17.0” which will pick up 4.17.3

Yes, we are facing it too. And now revert to Node 8, it’s temporary ok