Start a new topic

Kinvey.init promise broken?

The Kinvey.init function is defined in the guide as

var promise = Kinvey.init({

appKey : 'App Key',

appSecret : 'App Secret'


promise.then(function(activeUser) {


}, function(error) {



but even if the credentials are wrong the success branch of the promise is invoked instead of the error branch.

See it for yourself

I would always recommend using after initializing to verify the connection and credentials (app key/secret) are valid. You can find usage example in the docs right below the Kinvey.init example.
Sure but that's not the point.
Hi Daniel - Unfortunately cannot really comment on underlying implementation reasons, as I don't work for Kinvey. At the least I just wanted to provide an alternative method for how you could check appKey credentials in case this problem was holding up any of your development.

It does appear that the promise for Kinvey.init is fulfilled (or rejected) based on user synchronization, so I believe the promise will fire off an error based on that.
Hi OhmzTech

don't get me wrong, I am very thankful for your advice that you gave me in your free time. I did not mark your reply as correct answer becuase I was still awaiting that Kinvey support will show up with "omg we have a bug in our public API, we are totally going to fix this ASAP" or something like that :).

Actually the promise works in strange way, I am going to implement it next week and I will be back if I found out more.

Thanks again.
Hey there Daniel,

I just wanted to let you know that we did see this and that we're looking into it. I didn't want to give you a reply publicly until we had a solid answer on this one way or another. We've had a lot of people on vacation due to the holidays, that are just returning now. We will start an investigation into why this isn't working as intended on Monday.

I'll be in touch as more information becomes available.

Thank you @OhmzTech‌, @daniel_sedlacek‌ For the time being, we at kinvey are recommending a workaround using the method that you OhmzTech mentioned (using ping rather than init) until we can dedicate some engineering cycles to looking into why init isn't working the way we think it should be.

I will update this topic when more information becomes available, but where ping() is working, this likely won't be addressed with critical priority

Thank you for the report,

It seems this is still broken. I've tried the following code:

  appKey: '<appKey>',
  appSecret: '<appSecret>'
}).then(function(activeUser) {
  // activeUser is null

  var activeUser = Kinvey.User.getActiveUser();
  var promise = Promise.resolve(activeUser);
  if (activeUser !== null) {
    promise =;
  .then(function(activeUser) {
    // activeUser is still null
  .catch(function(error) {
    // ...

}).catch(function(error) {
  // ...


 and activeUser is always null


The activeUser will be null before login is performed. Are you calling login after initialize and before getActiveUser?



Kinvey Support

1 person likes this


thanks for a prompt reply.

You're right, user wasn't logged in (v3 is using different keys in localStorage and other places than v1).

The part that got me confused is that the promise from example never fails (never calls `catch` callback), even if user isn't logged in. In what scenarios does it actually fail?



The call to Kinvey backend will typically fail and execute catch block because of following reasons: network interruption, insufficient credentials etc. Because your code executed correctly, it went into then execution block every time.

If you want to see catch block execution, you can disable wifi on your testing device/simulator before making a call to Kinvey backend.



Ok, thanks for clarifying. Doesn't "insufficient credentials" apply to this case too? Requesting current user details without valid session token seems like a credentials issue.

Login or Signup to post a comment