The scenario is as follows: create a node, then try to move it using a new session.
Will attach a test case.
Bulk close for the 0.9 release
Fixed at revision 1502689. Thanks for hunting this one down Alex!
Good catch. It seems Root.move doesn't touch the pending changes state. I'll have a look.
fyi I quickly checked, jackrabbit returns true on the #hasPendingChanges call
I think I have more info. I tracked down the missing #save call in sling .
It turns out the #save call is conditioned by a #hasPendingChanges check, to which oak returns false.
I have updated the test to reflect this latest details.
as discussed with Michael offline, the latest version of the test is lacking a #save call after the move.
I'm unsure at which point in the http post call the save happens, so I cannot yet fully reproduce the failing move test.
I'll try to find more info on this topic.
makes sense, I've tweaked the test to make it closer to what happens behind the scenes in my failing scenario: removed the failing assert (as Jukka mentioned it was not an issue), and added a getNode call with a new session which fails with a PathNotFoundException.
Worth to mention that the failure I see is based on the @MoveFrom functionality from the sling post servlet, and I think all the steps outlined in the provided test are done via http POST calls using new sessions, that's why I'm having a bit of a hard time reproducing this in a pure oak environment.
For reference, here are some sling integration tests that cover these bits.
Jukka is right here, I didn't realise this before.
The expectation encoded in the test case is apparently what the Sling PostServlet expects (personal communication with Alex, correct me when I got this wrong).
Looking at the test case, a node1.getSession().refresh() call seems to be missing. Note that with Oak sessions are based on snapshots of the repository state, so a refresh, either explicit or implicit (triggered for example by the auto-refresh feature), is needed for changes from another session to become visible. Also, we currently only track moves within a single session, so in this case node1 would actually become invalid after the refresh.
I pushed the test showing the issue (ignored currently) with rev http://svn.apache.org/r1502240