How to undo a ParseUser.setPassword() call?

Question

I am letting the user change his credentials. He types new username, email and password and I go like:

ParseUser user = ParseUser.getCurrentUser();
user.setUsername("MY NEW NAME");
user.setEmail(email);
user.setPassword("MY NEW PW");
user.saveInBackground(...);

So what? So this save() call might fail, for a big number of reasons (example: username already taken by someone else). I can tell that in this case none of the above fields gets updated, which is fair: I show an error, user knows that all went wrong.

Things get complicated if you notice that, even after the ParseException, the user above keeps its dirty fields, which couldn't be saved to the server. I.e.

//saveInBackground fails
//...
user.getUsername().equals("MY NEW NAME") // true!

Issue

Now, I am able to get these fields back to the right values by calling user.fetch(), but this doesn't work with the password field.

This is particularly unwanted, because any future call to save() or such (which might not fail because maybe it's a completely different call) will update the password too! I.e.

//later
ParseUser user = ParseUser.getCurrentUser();
user.put("stuff");
user.save();

This won't only put "stuff", but also change the password to "MY NEW PW".. without the user ever knowing.

Is there any way to reset the local password field, other than fetch() which doesn't work? I know I could save username, email and password with three different queries but that is not a possible solution for my case.

Answer 1

A workaround could be to use

+ becomeInBackground:

on PFUser class (with PFUser.currentUser().sessionToken as token) when save fails, but that is still a risk for becomeInBackground to fail. It could at least prevent some cases to happend if becomeInBackground effectively undoes setPassword, and accepts current sessionToken as parameter, I haven't tested that

Answer 2

Looking at the newest release I've read in the changelog:

V1.10.2 — SEPTEMBER 15, 2015

New: Added ParseObject.revert() and revert(key) to allow reverting dirty changes

Looks like this could be it. It was definitely needed.