Develop Reference

Firebase - How to extend FirebaseError?

I am implementing a cloud function for signing up with unique username and password.
In order to throw exceptions, I was previously doing the following:
signUpValidation.js
if (!validateUsername(username)) {
throw new functions.https.HttpsError(
"invalid-argument",
"Invalid username.",
{
status: "error",
code: "auth/invalid-username",
message: "Username must be between 3 and 30 characters, including numbers, letters, hyphens, periods, or underscores.",
}
);
}
signUp.function.js
try {
await validateSignUpData(
username,
email,
password,
repeatPassword,
name,
birthday,
clientIp
);
} catch(err) {
if (err instanceof functions.https.HttpsError) {
throw err;
}
// An unknown error has occurred
console.error(err);
throw new functions.https.HttpsError(
"unknown",
"Unexpected error.",
{
status: "error",
code: err.code ?? "unknown",
message: err.message ?? "The registration request could not be processed. Please, try again later."
}
);
}
But, I don't really like this way of throwing the exceptions in the signUpValidation module... it makes more sense to me to throw "AuthErrors" instead of "HttpsErrors".
So, as it seems not possible to extend the default Firebase Errors, I have decided to create my own util/authErrors module:
class AuthError extends Error {
constructor(code, message) {
super(message);
this.code = code;
this.name = "AuthError";
}
}
const authErrors = Object.freeze({
usernameAlreadyExists(message = "The username is already in use by an existing account") {
return new AuthError('auth/email-already-exists', message);
}
... more errors
});
module.exports = authErrors;
as you can see, I have created my custom Error and some factory functions for every error type. Then, in my signUpValidation.js, I just do:
if (!(await isUsernameUnique(username))) {
throw authErrors.usernameAlreadyExists();
}
Is it possible to extend a FirebaseError? If not, why?
Is it considered a bad practice to work this way in order to throw custom exceptions in Cloud Functions? I mean, should I just throw HttpsErrors?

Having Custom Error Type is useful if you are going to treat it differently.
For example if you have a try/catch block and want to have a different logic for your custom error.
but here you are passing error to client which has no idea of either Firebase HttpsError or your custom AuthError. because at the end your object will be serialized to JSON and at the other end there is no class to convert it back to HttpsError or AuthError.
Also at HTTP protocol level, authentication errors are defined by HTTP status codes (e.g. 401 ,403) so they are not inherently different object types.
What I'm saying is that I don't see any advantage in having a custom AuthError class on your server side when it can not be transformed as it is to your client to be treated differently.
For client the HTTP status code is the key to differentiate an Auth error from other type of errors.

How to read error messages from javascript error object

Could some one help me out on below question please :-)
I'm making a post call through redux action, which is below.
export const addEmployee = ({ firstName, surname, contactNumber, email }) => async dispatch => {
const payloadBody = JSON.stringify({ firstName, surname, contactNumber, email });
fetch('/api/users', {
method: 'POST',
body: payloadBody,
headers: {
'Content-Type': 'application/json'
}
})
.then(response => {
if (!response.ok) {
return response.text()
.then(text => {
throw Error(text)
});
} else {
dispatch(setAlert("New Employee added ", 'danger'));
}
})
.catch(error => {
console.log('>>> in CATCH block, error is =>', error);
console.log('>>> in CATCH block, error name is =>', error.name);
console.log('>>> in CATCH block, error message is =>', error.message);
let allKeys = Object.getOwnPropertyNames(error);
console.log(allKeys);
// const errors = [];
// Object.keys(error.message).forEach(key => {
// console.log('>>> key are ', key)
// })
// const keys = Object.keys(error.message);
// console.log(keys);
// const errors = error.message['errors'];
// const errors = error.response.data.errors;
// if (errors) {
// errors.forEach(error => dispatch(setAlert(error.msg, 'danger')));
// }
dispatch({
type: REGISTER_FAIL
});
})
}
Above post call on failure, returns body with error message, an example is below
{
"errors": [
{
"msg": "User already exist with email"
}
]
}
Question
What I'm trying to achieve is, to grab the errors[] and pass the error message through to a component, the trouble I have is accessing the error[] array within the returned array message. I'll describe below what I've attempted, it also can be seen in the redux action method I posted above.
Try-1
console.log('>>> in CATCH block, error is =>', error); yields just Error
Try-2
console.log('>>> in CATCH block, error name is =>', error.name); yields {"errors":[{"msg":"User already exist with email"}]} and the typeof this is string since I'm returning text() return response.text().then(text => { throw Error(text) })
Try-3
When I return as json() return response.json().then(text => { throw Error(text) })and console.log('>>> in CATCH block, error message is =>', error.message); yields object.
The questions again What I'm trying to achieve is, to grab the errors[] and pass the error message through to a component such as below
const errors = error.message; // this is where I'd like to extract the error.
if (errors) {
errors.forEach(error => dispatch(setAlert(error.msg, 'danger')));
}
Hope the above description is clear, please let me know if you require more info,
I know I'm missing some crucial knowledge of working with error objects, could someone please shed some light on this please :-)

Pattern for throwing errors recovered from standard-format HTTP payload
Your redux action does work over HTTP. Sometimes the server responds with bad news, and it seems like there's a standardized format the server uses to report that news. Also, sometimes your own code throws. You want to handle both kinds of problem with control structures related to Errors.
Basic pattern for an async Redux action
Before we start: your action is marked async, but you're still chaining .then and .catch. Let's switch to async/await, converting this:
export const addEmployee = (/*...*/) = async ( dispatch, getState ) => {
fetch(/* ... */)
.then(response => {
return response.text()
.then(text => {
// happy-path logic
throw Error(text)
})
})
.catch(error => {
// sad-path logic
dispatch(/* ... */)
})
}
...into this:
export const addEmployee = (/*...*/) = async ( dispatch, getState ) => {
try {
let response = await fetch(/* ... */)
let responseText = await response.text()
// happy-path logic
dispatch(/* ... */)
return // a redux action should return something meaningful
} catch ( error ) {
// sad-path logic
dispatch(/* ... */)
return // a failed redux action should also return something meaningful
}
}
Now let's talk about errors.
Error basics
Meet throw:
try { throw 'mud' } catch( exception ) { /* exception === 'mud' */ }
try { throw 5 } catch( exception ) { /* exception === 5 */ }
try { throw new Date() } catch( exception ) { /* exception is a Date */ }
You can throw just about anything. When you do, execution halts and immediately jumps to the closest catch, searching all the way through the stack until it finds one or runs out of stack. Wherever it lands, the value you provided to throw becomes the argument received by catch (known as an "exception"). If nothing catches it, your JS console logs it as an "uncaught exception."
You can throw anything, but what should you throw? I think you should only throw instances of Error, or one of its subclasses. The two main reasons are that the Error class does some helpful things (like capturing a stacktrace), and because one of your two sources of failure is already going to be throwing Error instances, so you must do something similar if you wish to handle both with a single codepath.
Meet Error:
try {
throw new Error('bad news')
} catch ( error ) {
console.log(error.message)
//> 'bad news'
}
We already know that an Error will be thrown if code within your action blows up, e.g. JSON.parse fails on the response body, So we don't have to do anything special to direct execution onto the catch path in those scenarios.
The only thing we have to be responsible for is to check whether the HTTP response contains something that looks like your server's "standard error payload" (more on that later), which your sample suggests is this:
{
"errors": [
{
"msg": "ERROR CONTENT HERE"
}
]
}
Here's the core issue
This handling has to be special because no javascript engine considers it an error simply to receive an HTTP payload that can be parsed as JSON and which contains a key named "errors". (Nor should they.) This payload pattern is merely a custom convention used by some or all of the HTTP endpoints that you talk to.
That's not to say it's a bad idea. (I think it's great!) But that explains why it must be done custom: because this pattern is just your private little thing, and not actually special in a way that would make browsers treat it the special way you want.
So here's our plan:
make the request, relying on try/catch to capture things thrown by our tools
if we get a response that seems bad:
examine the payload for an error encoded in the "standard format"; I call anything like this an "API error"
if we find an API error, we will create and throw our own Error, using the API error content as its message
if we don't find an API error, we'll treat the raw body text of the response as the error message
if we get a response that seems good:
dispatch the good news (and useful data) to the store
Here's what that looks like in code:
export const addEmployee = ({
firstName,
surname,
contactNumber,
email
}) => async ( dispatch, getState ) => {
const payloadBody = {
firstName,
surname,
contactNumber,
email
}
try {
// step 1
let response = await fetch('/api/users', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(payloadBody)
})
let responseText = await response.text()
if (!response.ok) {
// step 2
let errorString = getErrorMessageFromResponseBody(responseText)
throw new Error(errorString) // API errors get thrown here
}
// step 3
let responseJson = JSON.parse(responseText)
dispatch(setAlert('New Employee added', responseJson.user.name))
/*
A redux action should always returns something useful.
addEmployee might return the `user` object that was created.
*/
return responseJson.user
} catch ( error ) {
// all errors land here
dispatch({
type: REGISTER_FAIL,
message: error.message
})
/*
A failed redux action should always return something useful (unless you prefer to throw).
For now, we'll return the reason for the failure.
*/
return error.message
}
}
function getErrorMessageFromResponseBody( string ) {
let errorString = string
try {
let json = JSON.parse(string)
if(json.errors) {
errorString = json.errors[0].msg
}
} catch ( parseOrAccessError ) {}
return errorString
}
Here's what can be thrown to that catch block:
anything thrown by JSON.parse when applied to the arguments
anything thrown by fetch
if !response.ok, the whole response payload (or just an error message if the payload contains an API error)
Exception handling
How can you tell those different kinds of failure apart? Two ways:
Some failures throw specific subclasses of Error, which you can test for with error instanceof SomeErrorClass:
JSON.stringify throws a TypeError if it can't serialize its argument (if you have custom .toJSON anywhere, it can also throw anything that throws)
fetch throws a TypeError if it can't reach the internet
JSON.parse throws a SyntaxError if the string can't be parsed (if you use a custom reviver, those errors get thrown too)
Any instance of Error or its subclasses will have a .message; you can test that string for specific cases
How should you handle them?
If JSON.stringify blows up, it's because you wired your data wrong. In that case, you probably want to do something that will alert the developer that something is broken and help diagnose the issue:
console.error(error)
dispatch some failure action that includes the error.message
show a generic error message on-screen
If fetch throws, you could dispatch a failure that presents a "fix your wifi" warning to the user.
If JSON.parse throws, the server is melting down, and you should show a generic error message.
A little sophistication
Those are the basic mechanics, but now you confront a messy situation. Let's list some challenges:
You may have already noticed one problem: "no internet" will present the same way as "circular data": a thrown TypeError.
It turns out that the precise text of JSON.stringify errors depends on the actual value supplied to that function, so you can't do something like error.message === CONSTANT_STRINGIFY_ERROR_MESSAGE.
You may not have an exhaustive list of every msg value the server can send in an API error.
So how are you supposed to tell the difference between a problem reported by a sane server vs a client-side bug vs a broken server vs unusable user data?
First, I recommend creating a special class for API errors. This lets us detect server-reported problems in a reliable way. And it provides a decent place for the logic inside getErrorMessageFromResponseBody.
class APIError extends Error {}
APIError.fromResponseText = function ( responseText ) {
// TODO: paste entire impl of getErrorMessageFromResponseBody
let message = getErrorMessageFromResponseBody(responseText)
return new APIError(message)
}
Then, we can do:
// throwing
if (!response.ok) {
// step 2
throw APIError.fromResponseText(responseText)
}
// detecting
catch ( exception ) {
if(exception instanceof APIError) {
switch(APIError.message) {
case 'User already exist with email':
// special logic
break
case 'etc':
// ...
}
}
}
Second, when throwing your own errors, never provide a dynamic string as the message.
Error messages for sane people
Consider:
function add( x, y ) {
if(typeof x !== 'number')
throw new Error(x + ' is not a number')
if(typeof y !== 'number')
throw new Error(y + ' is not a number')
return x + y
}
Every time add is called with a different non-numeric x, the error.message will be different:
add('a', 1)
//> 'a is not a number'
add({ species: 'dog', name: 'Fido' }, 1)
//> '[object Object] is not a number'
The problem in both cases is that I've provided an unacceptable value for x, but the messages are different. That makes it unnecessarily hard to group those cases together at runtime. My example even makes it impossible to tell whether it's x or y that offends!
These troubles apply pretty generally to the errors you'll receive from native and library code. My advice is to not repeat them in your own code if you can avoid it.
The simplest remedy I've found is just to always use static strings for error messages, and put some thought into establishing conventions for yourself. Here's what I do.
There are generally two kinds of errors:
some value I wish to use is objectionable
some operation I attempted has failed
In the first case, the relevant info is:
which datapoint is bad; I call this the "topic"
why it is bad, in one word; I call this the "objection"
All error messages related to objectionable values ought to include both datapoints, and in a manner that is consistent enough to facilitate flow-control while remaining understandable by a human. And ideally you should be able to grep the codebase for the literal message to find every place that can throw the error (this helps enormously with maintenance).
Here is how I construct the messages:
[objection] [topic]
There is usually a discrete set of objections:
missing: value was not supplied
unknown: could not find value in DB & other "bad key" issues
unavailable: value is already taken (e.g. username)
forbidden: sometimes specific values are off-limits despite being otherwise fine (e.g. no user may have username "root")
invalid: heavily overused by dev community; treat as option of last resort; reserved exclusively for values that are of the wrong datatype or syntactically unacceptable (e.g. zipCode = '__!!#')
I supplement individual apps with more specialized objections as needed, but this set comes up in just about everything.
The topic is almost always the literal variable name as it appears within the code block that threw. To assist with debugging, I think it is very important not to transform the variable name in any way.
This system yields error messages like these:
'missing lastName'
'unknown userId'
'unavailable player_color'
'forbidden emailAddress'
'invalid x'
In the second case, for failed operations, there's usually just one datapoint: the name of the operation (plus the fact that it failed). I use this format:
[operation] failed
As a rule, operation is the routine exactly as invoked:
try {
await API.updateUserProfile(newData)
} catch( error ) {
// can fail if service is down
if(error instanceof TypeError)
throw new Error('API.updateUserProfile failed')
}
This isn't the only way to keep your errors straight, but this set of conventions does make it easy to write new error code without having to think very hard, react intelligently to exceptions, and locate the sources of most errors that can be thrown.
Handling server inconsistencies
A final topic: it's pretty common for a server to be inconsistent about how it structures its payloads, particularly with errors but also with successes.
Very often, two endpoints will encode their errors using slightly different envelopes. Sometimes a single endpoint will use different envelopes for different failure cases. This is not usually deliberate, but it is often a reality.
You should coerce all the different flavors of server complaint into a single interface before any of this madness can leak into the rest of your application, and the shore of the client/server boundary is the best place to immediatley jettison server weirdness. If you let that stuff escape into the rest of your app, not only will it drive you insane, but it will make you brittle by allowing the server to surface errors deep inside your app, far away from the real source: a violated API contract.
A way to support a variety of envelopes is by adding extra code to getErrorMessageFromResponseBody for each of the different envelopes:
function getErrorMessageFromResponseBody( string ) {
let errorString = string
/*
"Format A"
{ errors: [{ msg: 'MESSAGE' }] }
used by most endpoints
*/
try { /*... */ } catch ( parseOrAccessError ) {}
/*
"Format B"
{ error: { message: 'MESSAGE' } }
used by legacy TPS endpoint
*/
try { /*... */ } catch ( parseOrAccessError ) {}
/*
"Format C"
{ e: CODE }
used by bandwidth-limited vendor X
use lookup table to convert CODE to a readable string
*/
try { /*... */ } catch ( parseOrAccessError ) {}
return errorString
}
One of the values of having a dedicated APIError class to wrap these things is that the class constructor provides a natural way to gather all this up.

firebase auth applyActionCode method does not turn emailVerified to true

I am developing firebase authentication system where a user is sent email to verify email adr. I got everything working eventually. The user signs up and the email (with the link) is sent to the signed up edmail adr. I use custom email action handler (https://firebase.google.com/docs/auth/custom-email-handler) to respond to a click on the link. On my node.js express route, I get oobCode (which firebase documentation say is "A one-time code, used to identify and verify a request") and pass it as an argument to firebase.auth().applyActionCode(oobCode) which returns a void promise when resolved. see code below.
firebase.auth().applyActionCode(oobCode)
.then( () => {
return admin.auth().updateUser(currentUser.uid, {
emailVerified: true,
})
})
.then( () => {
return res.status(301).redirect(`../unps/${currentUser.uid}`)
})
.catch( (error) => {
return res.status(500).json({ unp_error: `error message: ${error.message} - error code:
${error.code}` })
});
My undestanding of the documentation is that, applyActionCode method, if resolved, will set the emailVerified to true but this does not happen even though there is no error. I had to call updateUser to change emailVerified to true. Shouldnt this be done automatically by the method applyActionCode if a valid oobCode is presented as argument? What am I missinmg? Pleaase help?

All information about the Firebase Authentication user in your application code is taken from the ID token. This ID token is valid for an hour, and automatically refreshed by the SDK about 5 minutes before it expires. Until the token is refreshed, it may not reflect the latest value of emailVerified or other information about that user profile on the server.
It is indeed normal that you need to force a refresh of the token, to get the updated status before it auto-refreshes. When you do that, you shouldn't have to call admin.auth().updateUser(...) though.

FirebaseError when logging out of web app, exception thrown by user callback, document references must have an even number of segments

I've built a Javascript web app using Firestore and Firebase. When logging the user out, I am getting console errors. The errors reference the firebase-database.js and firebase-firestore.js scripts, though, so I can't really tell what is happening:
[2020-05-22T12:32:58.436Z] #firebase/database: FIREBASE WARNING:
Exception was thrown by user callback.
Hr#https://www.gstatic.com/firebasejs/7.6.1/firebase-firestore.js:1:48219
firebase-database.js:1:11297
FirebaseError: Invalid document reference. Document references must
have an even number of segments, but user has 1
firebase-firestore.js:1:48219
This is my log out function:
$('.logout').on('click', function(){
firebase.auth().signOut()
.catch(function(error){
console.log(error.code);
console.log(error.message);
});
});
Then I have a listener for firebase.auth().onAuthStateChanged which triggers this:
firestoredb.collection('user').doc(uid).update({
status: false,
last_changed: firebase.firestore.FieldValue.serverTimestamp()
})
.then(function(){
uid='';
$('#screenname').html('');
window.location='https://www.example.com/your-account.asp?task=logout&afterlogin=%2Fv2';
})
.catch(function(error){
console.log(error.code);
console.log(error.message);
});
What might be my strategy for tracking down this error since the console logs are not that helpful? The error does not really affect the performance of the app, since the user is logged out anyway (and redirected via Javascript), however it bothers me that there is an error.
EDIT: I am wondering if the cloud script that is running could be the problem. That might explain why I cannot identify the line number and why the error message is so vague. Here is my cloud script, can this be modified so that a missing UID value would be ignored? This is basically the script provided by Google for combining Firebase and Firestore to maintain session state of the user.
const functions=require('firebase-functions');
const admin=require('firebase-admin');
admin.initializeApp();
const firestore=admin.firestore();
exports.onUserStatusChanged=functions.database.ref('user/{uid}').onUpdate(
async (change, context) => {
const eventStatus=change.after.val();
const userStatusFirestoreRef=firestore.doc(`user/${context.params.uid}`);
const statusSnapshot=await change.after.ref.once('value');
const status=statusSnapshot.val();
if (status.last_changed>eventStatus.last_changed){
return null;
}
eventStatus.last_changed=new Date(eventStatus.last_changed);
return userStatusFirestoreRef.update(eventStatus);
}
);

Need a way to systematically handle errors/exceptions/rejections in a NodeJS project

Background Info
I have a new project I'm working on that will provide multiple different (optional) packages that can be installed, all of which are in addition to the core package (only manual package). The other packages just interact with the core.
The project is just meant to keep track of lists of data (not very specific, I know, but these details aren't needed). The add-on packages determine HOW the lists of data are interacted with. The core package just consists of all the main JS functionality and database models, and authentication. The other packages tie into those.
Lets say you want to just have it as a standard web page, you can install the webui package, which will tie into the core, and create a web app for it
If you want to create an API, you can install the restapi package, which creates the RESTful interface; You can also install the spaui package which will interact with the RESTful interface, which gets the data from the core
These addon packages I will call "facade" packages. All you really need to extrapolate from the above is that the core is a separate package from the facade packages, and it handles the core functionality (Database stuff, authentication, authorization, etc)
Problem
The core can use promises or callbacks, and it returns exceptions for failures, then whatever facade package is used to interact with the core will handle the exceptions/errors (showing an HTTP error page, returning a RESTful error result, etc).
Since the package that handles the errors is different than the package that returns the errors, there needs to be a systematic way of knowing what type of error was returned, so it can be dealt with properly (EG: The webui/restui packages should know if it needs to show a HTTP 500, a HTTP 403, HTTP 409, etc). Obviously of the core just returns new Error('Something broke'), then the facade packages don't really know what type of error it is, unless they have the text saved somewhere and can match it up with an error code.
Question
Whats the best way to handle this? I haven't been able to find anything that accomplishes this exactly how I want..
I eventually started working on my own attempt.. (below)
My Possible Solution (If this is sufficient, just confirm)
I created a new AppError exception type, and instead of returning AppError exceptions with simple strings, you provide an error code which will associate that exception with the error message, error type, etc.
Here is an example usage of the AppError exception:
exports.createThing = ( name, data ) => {
return new Promise( ( res, rej ) => {
if( doesItExist( name ) )
return rej( new AppError( 'document.create.duplicateName' ) )
// Other stuff...
})
}
Now inside the AppError exception method, it takes the code and looks inside a list of exceptions (the code should be the key inside an object of exception data).
Heres an example of what the exception data object for the above exception would contain:
module.exports = {
'document.create.duplicateName': {
type: 'DocumentConflict',
message: 'Failed to create new document',
detail: 'The document name specified already exists, try another one'
}
}
Example Usage: Lets say we try to execute createThing with an already existing name (From within the webui package):
CorePackage.createThing( 'foobar', 'some data' )
.catch( err => {
/*
The err is now an instance of AppError
err.type -> DocumentConflict
err.message -> Failed to create new document
err.detail -> The document name specified already exists, try another one
*/
})
From here, it's as simple as associating the err.type value with a suitable HTTP error code! (which would probably be HTTP 409 Conflict). Obviously these associations can be kept in an object, making it easy to just retrieve the correct error code for any of the error type values returned. Then the text for the error code is right there in err.message and err.detail
This also makes it easy to introduce some type of locale into the application, as the error, as all that needs to be done is to edit the exception data object.
End of post
So if you think my solution above is a sufficient one, and you cant think of any problems, then please say so. Id like to know if it is or if it isn't. Even if you can't think of a proper solution, but you just know the one I created wont work, share that as well.
If you have an alternative solution, then that would work just as well!
Thanks

I think there are two basic ways to approach this:
code property: Create a new \Error object and assign the code property with information about the error. For example:
var err = new Error('Message');
err.code = "DocumentConflict";
Custom error objects. You could have a seperate Error object per error type that you have. For example, rather than having just AppError, you can have DocumentConflict error.
For projects where I am creating a RESTful API, I like to think in terms of error codes. For most projects, the endpoints will return one of the following codes:
400 (Bad Request)
401 (Credentials Error)
403 (Forbidden)
404 (Not Found).
500 (Internal Server Error).
These then become 'standard' types of Error that I pass around the application. A normal Error object is interpretated as an internal server error, so this will always pass 500 to the endpoint.
For example,
CredentialsError = function (message) {
Error.call(this, arguments);
Error.captureStackTrace(this, this.constructor);
this.message = message;
};
util.inherits(CredentialsError, Error);
CredentialsError.prototype.name = "CredentialsError";
And then just return/throw a new CredentialsError("Invalid password") object as necessary. To check the type of object, you can use instanceof. With Express, for example, you can have an error handler similar to the following:
app.use(function(err, req, res, next) {
var status;
if (err instanceof error.FieldError) {
status = 400;
} else if (err instanceof error.CredentialsError) {
status = 401;
/* etc */
} else {
status = 500;
}
if (status !== 500) {
res.status(status).send(JSON.stringify(
err,
null,
4
));
} else {
// for 500, do not output the error!
console.error(err.stack);
res.status(500).send({
message: "Internal Server Error"
});
}
});
It is also worth noting that you can defined your custom error object constructors to take more than just strings. For example, you can pass objects into a BadRequestError constructor to provide field-level error detail.
Now, in most cases, you can just propagate the errors and the response to the endpoint will make sense. However, there are cases where you want to transmute the type of error. For example, if you have a login endpoint, you might do a request to findUserByEmailAddress(). This could return a NotFoundError object, but you want to capture this in the signIn() function and transmute it to a CredentialsError.