better-firebase-functions icon indicating copy to clipboard operation
better-firebase-functions copied to clipboard

Unable to deploy v2 function with uppercase letter in function name

Open orbitcm-marcusrogers opened this issue 1 year ago • 10 comments

I'm working to update my functions to v2. I'm running into an issue with deploying v2 functions that have an uppercase letter in the function name. V1 functions with an uppercase letter in the function name deploy fine. V2 Functions with names that are all lowercase deploy fine. I know firebase-tools just released an update to support uppercase letters in v2 function names - I'm using that version.

The error I get is "Function 'myFunction' is not defined in the provided module."

If I don't use this package, I'm able to deploy a v2 function defined as:

exports.myFunction = onCall(() => { return true; })

...so it seems there's no issue on the Firebase side with v2 functions with uppercase letters in the function name.

Functions all work fine in the emulator (including v2 functions with an uppercase letter in the function name).

Anyone been able to deploy v2 functions with an uppercase letter in the function name using this package?

orbitcm-marcusrogers avatar Jun 15 '23 00:06 orbitcm-marcusrogers

Hi, it's not working at all for me. Neither emulator or deploy finds functions even if all is in lowercase I'm using node 18 as engine in package.json and "better-firebase-functions": "^6.0.0"

However, it works well when using exports.myFunction = onCall(() => { return true; })

// index.ts

import {exportFunctions} from "better-firebase-functions";
exportFunctions({__filename, exports});

// search.ts || callable/search.ts || callable/anything/search.ts
// Same for searchSomething.ts

import {HttpsError, CallableRequest, onCall} from "firebase-functions/v2/https";

export default onCall(
  {region: "europe-west1", maxInstances: 10},
  async ({data, auth}: CallableRequest ) => {
    if (!auth) {
      throw new HttpsError(
        "failed-precondition",
        "The function must be called while authenticated."
      );
    }
    console.log(data);
    return [];
  }
);

npm run shell
> ...
⚠  functions: Functions Emulator unable to start on port 5000, starting on 5001 instead.
✔  functions: Using node@18 from host.
i  functions: Loaded functions: 
No functions emulated.

djiworks avatar Jun 22 '23 07:06 djiworks

Did you get this working?

I also can't export anything at all.

The docs are a little contradictory...

In the Installation section is says we can name files like this src/auth/on-create.ts.

But then in the exportFunctions() Usage section it shows that we need to use the suffix .func.ts on files like ./http/new-user.func.ts. I assume that is so it know which files to use during the build process.

I have tried both variations and neither worked for me.

BenJackGill avatar Jul 13 '23 14:07 BenJackGill

Actually I think this might be more related to this issue where nothing is deployed when using Firebase-functions v4.

BenJackGill avatar Jul 13 '23 14:07 BenJackGill

Hi everyone, will investigate the issue. I use my own lib in my own projects so I'm usually aware of any issues or breaking changes - seems a few people are having issues with it. I have not had any of these issues in v4, I suspect it's related to how the code is transpiled before deployment.

george43g avatar Aug 07 '23 09:08 george43g

I'm also having an issue with this. I updated from ^4.0.0 to ^ 6.0.0 and now all my function got deleted (tested in staging environment). It's not detecting my functions after updating.

Additionally, it was failing for 2nd Gen functions.

cgossain avatar Oct 01 '23 19:10 cgossain

hey guys, just published version 6.0.1. Community has indicated that this should fix deploy issues people were having - give it a go and let me know if this fixes the issue. Such a regression is unfortunate and frustrating.

I have been thinking about having a dedicated firebase project to enable live testing of this package before every deployment, as this would catch these kinds of errors. However, this may be overkill. Given that all the deps are rolled up into a single dependency it surprises me that dep versions could cause an issue like this.

george43g avatar May 10 '24 09:05 george43g

Hi @george43g , thanks for the release! Hopefully this solved some of the other problems mentioned in this Issue, but unfortunately I'm still unable to deploy functions with an uppercase character.

I looked at the output when I run exportFunctions and there seems to be a difference between functions with an uppercase character and those without:

  foldername: {
    filename: [Function],
    fileName: [Function (anonymous)] { __endpoint: [Object] }
  },

Every function (like foldername.filename above) that is all lowercase has a value that is just the function. Once you add an uppercase character, the value is what you see in foldername.fileName above. I observed this when there is an uppercase character anywhere in the name of the function (i.e. folderName.filename would give the same output as foldername.fileName).

I took a look through your code and didn't see anything obvious that would cause this difference, but maybe you'll spot it since you're more familiar with it than I.

Thanks again for the package and support.

orbitcm-marcusrogers avatar May 10 '24 21:05 orbitcm-marcusrogers

Hi @george43g , thanks for the release! Hopefully this solved some of the other problems mentioned in this Issue, but unfortunately I'm still unable to deploy functions with an uppercase character.

I looked at the output when I run exportFunctions and there seems to be a difference between functions with an uppercase character and those without:

  foldername: {
    filename: [Function],
    fileName: [Function (anonymous)] { __endpoint: [Object] }
  },

Every function (like foldername.filename above) that is all lowercase has a value that is just the function. Once you add an uppercase character, the value is what you see in foldername.fileName above. I observed this when there is an uppercase character anywhere in the name of the function (i.e. folderName.filename would give the same output as foldername.fileName).

I took a look through your code and didn't see anything obvious that would cause this difference, but maybe you'll spot it since you're more familiar with it than I.

Thanks again for the package and support.

I recall there being a problem with uppercase chars with functions in general - can anyone confirm that functions with uppercase chars can be deployed when using function groups without BFF?

And that is indeed bizarre - I dont think there's anything in my code but it might be a result of breaking changes in dependencies.

george43g avatar Jun 24 '24 02:06 george43g

There was a bug regarding this originally, but it was fixed quickly a year ago or so. I'm away from my computer this week, so can't find the commit that fixed it right now. I have successfully deployed a grouped function with uppercase characters when not using this package.

Marcus

On Sun, Jun 23, 2024, 10:40 PM George @.***> wrote:

Hi @george43g https://github.com/george43g , thanks for the release! Hopefully this solved some of the other problems mentioned in this Issue, but unfortunately I'm still unable to deploy functions with an uppercase character.

I looked at the output when I run exportFunctions and there seems to be a difference between functions with an uppercase character and those without:

foldername: { filename: [Function], fileName: [Function (anonymous)] { __endpoint: [Object] } },

Every function (like foldername.filename above) that is all lowercase has a value that is just the function. Once you add an uppercase character, the value is what you see in foldername.fileName above. I observed this when there is an uppercase character anywhere in the name of the function (i.e. folderName.filename would give the same output as foldername.fileName).

I took a look through your code and didn't see anything obvious that would cause this difference, but maybe you'll spot it since you're more familiar with it than I.

Thanks again for the package and support.

I recall there being a problem with uppercase chars with functions in general - can anyone confirm that functions with uppercase chars can be deployed when using function groups without BFF?

— Reply to this email directly, view it on GitHub https://github.com/george43g/better-firebase-functions/issues/57#issuecomment-2185480207, or unsubscribe https://github.com/notifications/unsubscribe-auth/A54EHF6RRE743ZRN37TUPYLZI6BIZAVCNFSM6AAAAAAZHCTRIWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBVGQ4DAMRQG4 . You are receiving this because you authored the thread.Message ID: @.***>

orbitcm-marcusrogers avatar Jun 24 '24 11:06 orbitcm-marcusrogers

@george43g After some debugging I found that, while v2 function names are camel case, the actual instances on which they are run (in Cloud Run) are all lower case. E.g. if I deploy a function users-getUsers the instance is named users-getusers.

More specifically, FUNCTION_NAME does not even exist in process.env on v2 functions, so with the current implementation we are actually reading just process.env.K_SERVICE, which is an all-lowercase string.

This means that in the following code snippet, funcNameMatchesInstance will always return false with the current implementation:

const getFunctionInstance = () => process.env.FUNCTION_NAME || process.env.K_SERVICE;
...
const funcNameMatchesInstance = (funcName: string) => funcName === getFunctionInstance();

A simple band-aid solution would be to do something like this:

const funcNameMatchesInstance = (funcName: string) => funcName.split("-").map(fragment => fragment.toLowerCase()).join("-") === getFunctionInstance();

Another solution is to read process.env.FUNCTION_TARGET, which would be something like "users.getUsers" and then use "." as a delimiter instead of "-" in the funcName string.

mathiasnh avatar Aug 12 '24 08:08 mathiasnh