firebase-tools: HTTP functions path incorrectly prefixed with "/[firebase-project-idx][firebase-region]"

I’m experiencing this after upgrade to 7.9.0, it seems like a big breaking change for local serving as it is not mentioned anywhere and it took me several hours to figure out it isn’t a bug in Angular Universal but a change in firebase tools instead.

It would be nice to mention this inconsistency with local serving somewhere as it might discourage people from deploying their functions as they do not work correctly locally.

Currently, I’m using replacing the prefix with request.baseUrl as a base should represent the prefix, but I’m not sure if it is the case in every possible scenario.

app.get('*', (req: express.Request, res: express.Response) => {

  req.originalUrl = req.originalUrl.replace(req.baseUrl, '');

  res.render('web-index', { req, res });

});

Is there a reason why the emulator serves functions with /<project-id>/<region> prefixed to the path at all? I can’t help but think that ~this~ doing away with these prefixes would solve not only the original bug in this issue, but alleviate the problem I’m having as well. After all, isn’t the idea behind an emulator to mirror something as closely as possible? Including extra path segments runs against that grain.

But then again, I’m almost certainly missing something… 🤔

@abeisgoat Has this been resolved? For me, emulators:start and firebase serve are still adding the path prefix and I have to use the environment variable workaround suggested in https://github.com/firebase/firebase-tools/issues/1279#issuecomment-493280145

@christiannaths Thanks for your input, this is a great question and if I’m understanding correctly, you aren’t saying that the old emulator handled this well, just that the new one (with the change to match the old one) now breaks you?

If this is the case, then I think this will be a prime candidate to introduce into emulators:start so serve will have the same bug as the old emulator and emulators:start will make the prefix available in some way (along with some other IS_FIREBASE_EMULATOR type env.)

That being said, since the original issue that @tmcf reported is now fixed, @christiannaths can you open a new issue with your thoughts? Feel free to just copy/paste what you said here, I just want to keep things organized.

This was never fixed and was made worse with functions v2. Literally none of the developer responses here fix or even address the issue.

@vmasek there was no intentional behavior change in 7.9.0 could you open a new issue describing the value you’re seeing versus the value you expect? Thanks!

I had not tried out 69e1e1b yet and was waiting for 6.9.3

My current workaround is to set an environment variable when testing before starting the emulators

export XFIREBASE_FN_PREFIX=/[firebase-project-id]/us-central1
firebase emulators:start --only functions,hosting

In production, XFIREBASE_FN_PREFIX is not present so I default it to ‘/’. This effectively lets me determine where the request handlers have been mounted and route relative to the prefix in all environments.

Cheers.

@christiannaths our new emulator is replacing this one: https://github.com/googlearchive/cloud-functions-emulator

The path was set as a convention there. It’s baked into too many places to change it now without causing a lot of pain. For instance the Callable Functions SDK has this hardcoded assumption about emulated function paths.

Forgive me, but I think https://github.com/firebase/firebase-tools/commit/69e1e1bdce9506576754c448c5834e696207798a introduces some unexpected behaviour. As far as I can tell, there is now no way to get the actual request path when running functions in the emulator.

I think this recommendation should have been implemented:

Either the emulator should set the HTTP triggers without this prefix or the prefix should be available in config/environment so the functions can handle the request path correctly.

For example, I need to generate an oauth callback url for the google OAuth2Client. I managed this before by using a combination of request.protocol, request.headers.host, and request.path. After this change–given that request.path no longer reflects the actual path, and the actual path is not stored anywhere–I’m at a loss as to how I can accomplish this without some hackery.

Fix is merged in, please re-open if you’re still experiencing this once 6.9.3 is out.