55 results found
-
Consistent and documented behavior for on*WithAuthContext
When Functions use e.g. onDocumentCreatedWithAuthContext to handle Firestore event triggers, the meaning of event.authType and event.authId are not documented and are inconsistent between the production and emulator environments.
The documentation [https://firebase.google.com/docs/functions/firestore-events?gen=2nd#auth-context](here) says "For information about the data available in the authentication context, see..." and links to a page that is not specific to Firebase. That page lists some possible values, but it's not clear what values would be used. The most sensible guess is that authType would be "appuser" or "user" if the document was created from the client-side web SDK, and "serviceaccount" if created from a…
1 vote -
Improve Billing Verification and Support for New Firebase Users
Many new Firebase users face serious issues when trying to activate the Blaze plan due to strict and non-transparent billing verification processes.
In my case:
• I attempted to verify my billing using a Revolut card (registered under my name);
• All payment confirmations were approved through the Revolut mobile app (4–5 times), yet the verification still failed;
• No clear error explanation was provided, and I had no way to resolve the issue;
• I tried adding a backup Korean card, but the verification message never arrived in the Korean mobile banking app (SMS also didn’t arrive because my…2 votes -
Fix error messages when deploying Functions
Several error messages often occur when deploying Firebase Cloud Functions that should not occur. My first time attempting to deploy functions in a new project, I got:
i extensions: ensuring required API firebaseextensions.googleapis.com is enabled...
⚠ extensions: missing required API firebaseextensions.googleapis.com. Enabling now...Error: Request to https://serviceusage.googleapis.com/v1/projects/********/services/firebaseextensions.googleapis.com had HTTP Error: 429, Quota exceeded for quota metric 'Default requests' and limit 'Default requests per minute' of service 'serviceusage.googleapis.com' for consumer 'project_number:********'.
I don't know if that happens every time. It appears to be just a failure to wait long enough after enabling the API.
The second time, it got further, but…
1 vote -
Support .NET (C#) in Firebase Functions.
Firebase has .NET SDKs for the client and admin SDKS. It would be nice if Firebase Functions supported .NET (C#) especially since GCP Cloud Run Functions already support .NET.
3 votes -
Add Support for Aggregation Functions and Regex Filtering in Firebase Realtime Database
Firebase Realtime Database currently lacks support for aggregation functions (like sum, count, average) and regex-based data filtering. These features would simplify querying, reduce client-side processing, and improve performance, especially with large datasets. While Firestore offers some of these capabilities, Realtime Database remains the preferred choice for real-time syncing. Native support for these functionalities would greatly enhance its potential and usability.
6 votes -
Add support for local npm packages
Change the behavior of dpeloy for functions so that if a local (file based) npm package is listed in the package dependencies, the package will be uploaded with the function.
It is a major pain for local packages to not be supported in uploading cloud functions.
4 votes -
Enable source map support
Since Node 12 it has built-in source map support. For cloud run deployments we can start the node server with the flag --enable-source-maps, but for cloud functions we don't have this control.
I don't understand why we still need to install and register the source-map-support NPM package in our code to get source maps to work.
I suggest to have a configuration option that enables the flag, preventing us from having to manually install a package that is considered obsolete for newer versions of Node.
3 votes -
Allow secrets on scheduled functions
It's not clear in the documentation nor by implementation that secrets work with scheduled cloud functions. This seems to me like a major missing feature in security and consistency with the v2 cloud functions. Is the only solution using the cloud config for api keys/secrets?
We need to have something like:
exports.someScheduledFunction = onSchedule(
{
schedule: "every 60 minutes",
timeoutSeconds: 100,
secrets: [someToken.name],
},
async () => {
logInfo("Running every 60 min");...
}
);3 votes -
allow secrets on scheduled functions
It's not clear in the documentation nor by implementation that secrets work with scheduled cloud functions. This seems to me like a major missing feature in security and consistency with the v2 cloud functions. Is the only solution using the cloud config for api keys/secrets? Something like:
exports.someScheduledFunction = onSchedule(
{
schedule: "every 60 minutes",
timeoutSeconds: 100,
secrets: [someToken.name],
},
async () => {
logInfo("Running every 60 min");...
}
);3 votes -
Fix Body Parse
If bad JSON is sent to a cloud function, for example if the function is an API endpoint, the body-parse in Firebase Functions will throw an HTML response error before and user function code is run.
This is a really bad experience for endpoint users where instead of a formatted JSON error message, they get a strange HTML response.
The body-parser used in by Firebase Functions should pass along the error instead of returning the response.
4 votes -
Automatic Deployment of Changed Firebase Functions
Firebase should offer a built-in feature to automatically detect changes to Cloud Functions and deploy only those functions, grouped into manageable batches to avoid rate limits. This feature would streamline deployments by:
- Scanning the project directory to identify functions with modified code since the last deployment.
- Automatically batching the deployment of changed functions based on rate limit thresholds (e.g., 8-10 functions per batch).
- Handling the deployment process transparently within the Firebase CLI or CI/CD integrations, reducing manual intervention.
This functionality would save time, minimize deployment errors, and improve developer workflows, particularly in large projects with numerous functions.
27 votes -
Automatic Deployment of Changed Firebase Functions
Firebase should offer a built-in feature to automatically detect changes to Cloud Functions and deploy only those functions, grouped into manageable batches to avoid rate limits. This feature would streamline deployments by:
- Scanning the project directory to identify functions with modified code since the last deployment.
- Automatically batching the deployment of changed functions based on rate limit thresholds (e.g., 8-10 functions per batch).
- Handling the deployment process transparently within the Firebase CLI or CI/CD integrations, reducing manual intervention.
This functionality would save time, minimize deployment errors, and improve developer workflows, particularly in large projects with numerous functions.
3 votes -
Cloud Functions versioning
It will be great to have an easy way to deploy different versions of our API and access them by adding a "v1" or "v2" to the URL.
Currently, we can do it manually by changing the name of the function, but the ideal is to have a new parameter in the deployment process (CLI) to "group" them in versions.
This idea is great to roll out and have different versions living side by side until the production version that uses the new API is released to all the users.5 votes -
Make Firebase Functions Test a First Grade citizen
A solid Firebase Functions experience requires a fully functional test suite.
Firebase-functions-test is already there, and provides the experience, but is often forgotten for months.Firebase functions 6 was released a month ago, and it broke functions-test.
There's currently a patch that fixes it, and it's been there for a week.
This idea isn't about this issue. It's about giving resources to the firebase-functions-text project, so it can continue growing and thus giving cloud firebase functions users a solid testing experience before deploying.
4 votes -
Rolex Enterprises
Chair service
3 votes -
Should add basic REDIS/ Memcache Like Capability
Why I Want This?
Firebase splits functions to individual Docker Container. This works great for scaling, but with that it is not easy to share global values, for example, user's access key to external services and session specific values.
While we can use REDIS and such hosted on GCP, it would be more "batteries included" platform if this feature is offered as a built-in functionality for the functions without resorting to Firestore or RTDB.
What I look for is to globally share key values and also auto-expire them.
2 votes -
Sub Collection View
I feel the window to view sub collection on the firebase firestore console could be expandable.
2 votes -
It is necessary to change and update in advance the spread of better ideas that benefit people and reduce harmful materials
It is necessary to change and update in advance the spread of better ideas that benefit people and reduce harmful materials
2 votes -
Tell people that mixing V1 and V2 config files in the same project will create a port and container error.
Tell people that mixing V1 and V2 config files in the same project (note: even outside the gen2 function) will create a port and container error. Right now you don't mention in the docs or anywhere that having ANY function.config files in a project with a gen 2 function will cause a deploy error that says a container is broken and the port is unreachable. This error is misleading. It will also show the gen 2 function in the console as "unknown trigger" which also is misleading.
In all your documentation you say you can have gen1 and gen2 functions…
2 votes -
not upgrading blaze plan
firebase is not updateing to blaze plan i already have an verified billing account you should have to give more information about how to setup properly
4 votes
- Don't see your idea?