Added on the list for 2.16.
#13066

@harryadel out of curiosity, why do you call this internal method in your app?

@jamauro We've this unique case in our application where we have the user sha256 client-hashed password and some other meta data regarding the user document so we end up stitching these properties together and using an internal creation method (_createUserCheckingDuplicates in our case) to make the final user document and allow him to login.

@nachocodoner I ended up asyncfying addEmail and setUsername since they were using _checkForCaseInsensitiveDuplicates inside their functions.

On the 3.0 branch is this fixed? Is the accounts-password package completely free of sync db-calls??

On the 3.0 branch is this fixed? Is the accounts-password package completely free of sync db-calls??

It seems that is adapted actually. If you look into the release-3.0 branch you will see the code using async, and the ones you adapted here, already migrated.

In the changelog we keep the list of package's API that have been migrated to async, for instance, for the accounts-password package. So, your PR here will produce a breaking change for apps in Meteor 2.x, that make use of exposed API behaviors addEmail and setUsername which will be resolved as promise on next 2.16. But this migration will make ready for Meteor 3.x as stated above those are already async.

Alternatively we could have async versions for addEmailAsync and setUsernameAsync , the same way we have for Accounts.setPasswordAsync. But as they are migrated already as async in Meteor 3.x it may not be required.

cc @Grubba27, @denihs

Our philosophy so far has been to get everything asyncified, just like you mentioned with Accounts.setPasswordAsync so that when we run meteor update 3.0 there's very little to no work (the final step rather than it being another minor step.

Though my opinion on this isn't set in stone, let's see what Denis & Grubba has to say about this.

I would go in the safe route here...

We decided to create those *Async APIs to help out the migration, and following that pattern here is the way to go.

We should focus on not breaking changes and making those breaking changes as easy as possible for those making the transition.

We could have addEmailAsync and setUsernameAsync, leaving those without an async name until 3.0, when addEmailAsync and setUsernameAsync become aliases to their non-Async counterparts.

// 2.x

Accounts.addEmail // <- sync
Accounts.addEmailAsync // <- resolves to promise

// 3.x

Accounts.addEmail // <- resolves to promise it is just an alias to the addEmailAsync
Accounts.addEmailAsync // <- resolves to promise

That makes sense. We didn't do the same for 3.x and instead change to async directly. But we may change this now, since I don't think compromise a lot. So, if you can adapt this @harryadel to use async versions instead, that would be great.

@nachocodoner so I'd duplicate the functions and create async alternatives so it doesn't break anything for 2.x or just change the variables names to use the async prefix?

I'd duplicate the functions and create async alternatives so it doesn't break anything for 2.x

This is better to stick into the convention. This way we won't force any breaking changes on the new update.

We plan to release this week 2.16.

@harryadel: Do you want to include this on release 2.16? How is the state of the feedback applied?

We should create async versions as stated here and keep easy migration with 3.x, #13076 (comment)

I had initially started this PR to help ease our migration to 3.0 but since we're already attempting to migrate to the latest RC it seizes to grant any value for us. Plus, it was discarded in 2.16 release.