The function worke perfectly, but if I want to print the content of the user, I receive in the firebase log this info:
Function returned undefined, expected Promise or value
The function is:
exports.accountCreate = functions.auth.user().onCreate(user => {
console.log("--->"+user.data);
console.log("ok");
});
Why the user.data is not able to retrieved the informations?
Thanks
Cloud Functions run in a container in a managed environment. The environment tries to minimize how long it keeps the container running, and to be able to do so, it must know when your function is done. Normally in JavaScript code is done when the last } has executed, but this gets more complex when you also need to consider asynchronous operations. For this reason Cloud Functions expects you to inform it when the function is done, in the case of functions.auth.user().onCreate by returning a value or promise.
When you explicitly return a value, it is clear that the function is done. When you explicitly return a promise, it's clear that the function needs to remain active until the promise is resolved/rejected. When you don't return a value, it is not clear what state the function is in.
In your case the fix is simple, and you for example just return true before the final }.
exports.accountCreate = functions.auth.user().onCreate(user => {
console.log("--->"+user.data);
console.log("ok");
return true;
});
The actual value is meaningless btw, a return null would work just as well.
Related
Nothing happens to my firestore when I call the function below. I also can't see "inside helloWorld" on my GCP logs.
exports.helloWorld = functions.https.onCall((data, context) => {
console.log("inside helloWorld);
const users = admin.firestore().collection('users');
users.doc(data.userId).get().then( // --------------------Line A
(snapshot) => {
if (snapshot.exists) {
console.log("snapshot exists");
return null;
} else {
console.log("inside else");
users.doc(data.userId).set({
name: data.name
});
return null;
}
}
).catch(() => 'obligatory catch');
return; //-----------------------------------------------Line B
});
However, when I place the return on Line A, the function works as expected and a document is created in my firestore. "inside helloWorld" is shown on my GCP logs.
Why is that so?
I really appreciate any levels of clarification.
According to the documentation for callable functions (particularly the part about sending back a result):
To return data after an asynchronous operation, return a promise. The
data returned by the promise is sent back to the client. For example,
you could return sanitized text that the callable function wrote to
the Realtime Database.
Even if you don't want to send any content in the response, Callable functions still need to respond to the HTTP request that originated them, as all HTTP transactions do.
In either case, you still need to make use of the promises in all your async calls so that Cloud Functions knows when to respond to the client, after all the work is complete. Placing the return statement on "line A" is effectively returning the promise from the async work started by get(), fulfilling this requirement. Without the return statement, Cloud Functions is terminated your function because it thinks there is no more work to complete in order to send the final response.
If you're not familiar about how promises work in JavaScript, watch my video tutorials here: https://firebase.google.com/docs/functions/video-series/
What is the correct way to test if a function gets aborted by returning?
myFunction (parameter) {
if (typeof parameter === 'object') return
// doing any stuff
}
Test (jestJS)
it('myFunction() should return if no valid parameter is passed', () => {
// SETUP
wrapper = shallow(<Component />)
// EXECUTE
wrapper.instance().myFunction(undefined)
// VERIFY
// ??
})
What is the correct way to test if a function gets aborted by returning?
The only things you can do are:
Have the function return different values depending on the code path, and test the return value. (Your function as shown doesn't have a return value on either path, so the result of calling it is undefined, but if doing any stuff includes return something and something is guaranteed not to be undefined, you could test for that.)
Test for any side-effects the function has.
E.g., unless you provide a means of knowing what happened inside the function, there's no way to tell from outside it.
A function will always return - unless it throws an exception (The correct way to abort). If function aborts correctly with an exception, one can assert whether that exception was thrown or not.
If you'd like to test that a method executes to a particular line of code within the method. Assuming you have jasmine on board, you could create a spy on an object within the execution line, and test that spy with assertions.
Otherwise, there is no real way to distinguish between an abort by returning - unless the function is expected to return something and returns nothing.
I initially assumed that passing a bare Promise.mapSeries(...) call as an argument to .then() would be the same as wrapping it in a function, like .then(function() { return Promise.mapSeries(...); }). Having written out this question, I'm no longer entirely sure why it works at all.
In the simplified code below, I open a couple of databases asynchronously (openDBAsync()) and then read a file containing a JS object. I use _.map() to iterate over all of the key/value pairs in the object and asynchronously update their values in a database, while keeping track of which ones meet certain criteria (whether the value is odd, in this toy example). Promise.all() waits for all of the async database calls to settle, and then Promise.mapSeries() is used to process each of the subset of keys, which makes another async database call for each one. Finally, I close all the databases.
function processData(path)
{
var oddKeys = [];
return openDBAsync()
.then(function() { return readFileAsync(path); })
.then(function(dataObject) {
return Promise.all(_.map(dataObject, function(value, key) {
if (value % 2) {
oddKeys.push(key);
}
return updateDBAsync(key, ++value);
}))
.then(Promise.mapSeries(
oddKeys,
function(key) {
return updateOddDBAsync(key);
}
))
})
.then(closeDBAsync);
}
The problem is that the database throws errors complaining that I'm trying to update the database after it's been closed. That means that some of the promises generated in the .mapSeries() call are being called after the final closeDBAsync(). I expected all of them to settle before the final .then() call.
If I wrap the call to Promise.mapSeries() in a function:
.then(function() {
return Promise.mapSeries(
oddKeys,
function(key) {
return updateOddDBAsync(key);
}
);
})
Then I don't get any errors. It also works if I put a .delay(2000) before the close database call, which indicates that Promise.mapSeries() isn't settling all of the promises before it finishes.
This seems like either a bug in Bluebird, or, much more likely, I'm not understanding something fundamental about how Promise.mapSeries() works. Any guidance would be much appreciated.
much more likely, I'm not understanding something fundamental about how Promise.mapSeries() works
Nope, this seems to be more a misunderstanding about how .then(…) works.
The then method of promises does always take a callback function (if you're passing anything else [but null], Bluebird should spit out a warning!). By calling .then(Promise.mapSeries(…)), you were passing a promise instead, which is simply ignored. Being ignored, it also is not awaited by anything, which leads to that error of the database being closed too early.
But the direct call to Promise.mapSeries() doesn't get applied to the array immediately. If it was, the array would be empty and this code wouldn't work at all.
Yes it does. Your array is filled from by the _.map callback, which is executed synchronously, before then and mapSeries are invoked.
So the solution is indeed to wrap the call in a function expression, which will only be executed when the Promise.all(…) fulfills, and whose result will then not be ignored but rather awaited. There might be more, different solutions, depending on what degree of parallel execution you want to allow.
Btw, given you are doing a database transaction, your current code is quite fragile. Look into the promise disposer pattern.
My service needs to retrieve a value asynchronously, but once I have it, I'd like to used a cached version of the value.
When two controllers call this service, I'd expect the first one to cache the retrieved value and the second one to use the cached value, but according to the log, I never find a cached value. When this runs, I see a log message that shows the value being cached, then, when I follow an angular route to a different controller, I do not see that the service finds the cached value. Why does it not run according to my expectation**?**
angular.module('myApp.services').factory('Config', function() {
var Config = { };
Config.currentYear = function() {
if (Config._currentYear) {
// sadly, we never execute here
console.log("returning cached year");
return Parse.Promise.as(Config._currentYear);
}
return Parse.Config.get().then(function(config) {
console.log("caching year");
Config._currentYear = config.get("currentYear");
return Config._currentYear;
});
};
return Config;
});
A couple notes: (1) I named the cached attribute _currentYear, adding the underscore to avoid colliding with the function name. Not sure if I need to do that. (2) I return a fulfilled promise when the value is cached, so the function always returns a promise...also not sure if that's needed, but figure it can't hurt.
Instead of caching the data, why don't you just cache the promise and return it. When you cache the data, you are setting the data Config._currentYear only within the success callback and there are chances that other subsequent call(s) happening before the success callback is run. So you end up making the same call again. You can easily see this when you have calls made to the same service method from different controllers which are instantiated, by their presence on the same template. Caching a promise upfront will avoid these issues.
angular.module('myApp.services').factory('Config', function() {
var config; //Just use to save the promise
Config.currentYear = function() {
/*If there is already a call made before return the promise else
make the actual call and store the promise in the variable.*/
return config || config = Parse.Config.get().then(function(config) {
return config.get("currentYear");
});
};
});
I would like to return x || $.get.
Or in other words, if x is true, then return x, else perform a GET call and return the value provided by the server.
My attempt is listed below (ideally, it would follow the return x || y format maybe with an anonymous function? instead of the if/then).
Problem is my return from my $.get function appears not to be what I expected.
Would appreciate an explanation of what is going on.
Thanks
$(function(){
function test(x,y) {
if(x==true) {return true;}
else{
//test.php is echo($_GET['y']==123);
$.get('ajax.php',{'y':y},function (status) {return status;});
}
}
alert(test(false,123));
});
If you're using jQuery 1.5 or later, Deferred and Promise are your friend for this kind of thing. Any time you call AJAX calls what you get back are Promise objects which you can attach functions to via .done(), .fail(), and .then().
However! As pointed out by this excellent intro to deferred/promise and all this stuff (http://www.erichynds.com/jquery/using-deferreds-in-jquery/), you can also use $.wait()'s ability to handle a value that isn't a promise to automatically do caching. So code like this:
$.when(getToken()).done(
function (token) {
// do something with the token, which may or may not have been
// retrieved from the remote service
}
);
Can handle getting either a cached value back or a promise with no problem:
function getToken() {
// Return either the cached value or a jQuery Promise. If $.when() gets the
// cached value it will immediately realize that you didn't give it a
// promise and it will instead create a jQuery Deferred to return and
// .resolve() it using the value it did get. Thus, either way what
// comes out of the function is something .when() can deal with and call a function.
if (this.cache["token"]) {
return this.cache["token"];
} else {
return $.get(" ... some url ... ");
}
};