Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] in sample: firebase function (2nd generation) #1037

Open
coawazie opened this issue Feb 4, 2023 · 2 comments
Open

[BUG] in sample: firebase function (2nd generation) #1037

coawazie opened this issue Feb 4, 2023 · 2 comments

Comments

@coawazie
Copy link

coawazie commented Feb 4, 2023

Which sample has a bug?

Sample name or URL where you found the bug

const {onCall, HttpsError} = require("firebase-functions/v2/https");

const {onCall, HttpsError} = require("firebase-functions/v2/https");

How to reproduce the issue

Not sure how this can be reproduced: previous versions of same code had been deployed and currently in production. This started randomly.

Tl:Dr:

  • I have a few firebase functions (2nd generation) currently being tested in production
  • I deployed several iterations of one of the functions already
  • Then I refactored some code, tried re-deploying again, and suddenly, onCall imported from firebase-functions/v2/http stopped working

Failing Function code used (if you modified the sample)
Current code in production (and working) has onCall imported as a named import this way:
import {HttpsError, onCall} from "firebase-functions/v2/https"

After the deployment failure started, I fell back to using require as shown in the example I posted above. i.e.
const {onCall, HttpsError} = require("firebase-functions/v2/https");

Basic structure of what I have in production:

import * as admin from "firebase-admin";
import {HttpsError, onCall} from "firebase-functions/v2/https"
import {CallableRequest} from "firebase-functions/lib/common/providers/https";
import {APIRequestPayload} from "./typeDef"; //some custom type definition

exports.myfunctionname = onCall({
  enforceAppCheck: true,
  secrets: ["A_SECRET_I_USE"],
  region: "us-east1",
  cpu: 2,
  concurrency: 500,
  maxInstances: 15,
}, async (incomingData: CallableRequest) => { 

  const data: APIRequestPayload = incomingData.data;
  const secretVariable = process.env.A_SECRET_I_USE;

//
** some code logic
//

      if(someError) {
                    throw new HttpsError("internal", "Something went wrong");
          }

           return {codeLogicResult: somecodeprocessingresult}
})

Steps to set up and reproduce

  • Write a basic function
  • Run npm run deploy from the function folder

Debug output

Errors in the
console logs

Error: Failed to load function definition from source: Failed to generate manifest from function source: Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './lib/v2/providers/https' is not defined by "exports" in /Users/myuser/path_to_function_folder/functions/node_modules/firebase-functions/package.json

Screenshots

Screenshot 2023-02-03 at 7 01 38 PM

Expected behavior

Function should be deployed when npm run deploy is run from the cli as per documentation

Actual behavior

Function fails to deploy with the error message above

@kaumac
Copy link

kaumac commented May 19, 2023

Did you figure this out?

I'm having exactly the same error, tried reinstalling all dependencies, updating to newest version, nothing works...

@coawazie
Copy link
Author

Did you figure this out?

I'm having exactly the same error, tried reinstalling all dependencies, updating to newest version, nothing works...

Apparently Google randomly reduces quotas for projects at their discretion. Went through GCP, Cloud Run to be specific, to figure out the new quota limit. Closer look showed me the limits are per region, so my workaround is to deploy to different regions. Figure out your limit per region and plan your development accordingly, choosing regions with best performance for your performance-needing endpoints, and deploying other lower priority endpoints elsewhere.

This is not sustainable though when you have so many endpoints to maintain. AWS will be the way to go once you prove product feasibility as they're more straightforward and responsive.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants