Yes, that's right. Your fix did address the issue.
However, the problem with "rollback" is still there. It looks like you no longer have the rollback functionality, the way it was working in V1 (which, BTW worked great).
"refresh" function is not the same as "rollback".
Consider the following usecase.
1. AJAX calls are fired each time a Tree changes its state - DND, rename, creation, removal of nodes.
2. Backend code maintains the DB state and checks for external factors (e.g., validation).
3a. External factors may cancel the operation performed client-side (e.g, a node should not be deleted until dependent records are cleared first).
3b. Backend execution errors should propagate to client side, informing the user about the problem
4. AJAX "error" callback is fired when something goes wrong
5. The Tree should revert to prior state (a rollback is performed)
Using "refresh" in AJAX error callback does not address the issue. Consider this situation (the same usecase above):
0. INITIAL TREE STATE
1. A new node is created successfully
2. Some node is moved to new destination
3. An attempt to rename a node meets rejection by the backend (say, ACL has denied access).
Issuing refresh in "error" callback after step 3 would roll the entire tree back to state 0, results of steps 1 and 2 will be discarded.
The root of the problem is that the data you're using for "refresh" isn't maintained throughout the tree modifications.
Thanks!