The scenario is as follows: create a node, then try to move it using a new session.
Will attach a test case.
I pushed the test showing the issue (ignored currently) with rev http://svn.apache.org/r1502240
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.
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).
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.
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.
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.
fyi I quickly checked, jackrabbit returns true on the #hasPendingChanges call
Good catch. It seems Root.move doesn't touch the pending changes state. I'll have a look.
Fixed at revision 1502689. Thanks for hunting this one down Alex!
Bulk close for the 0.9 release