[JCRVLT-633] VLT RCP doesn't fail task when child node ordering error occurs

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 3.5.6
• Component/s: RCP
• Assignee: Unassigned
• Reporter: Irina Chirita
• Created: 31/May/22 08:44
• Updated: 31/May/22 14:15

Description

When using "VLT RCP Server Bundle" to copy content between servers, if there is a mismatch between the source and the target on the node type child ordering, then the process will stop silently. There is an error in the logs, however the task's JSON returns the status ENDED with HTTP code 200 suggesting processing has completed successfully. Therefore any tool making use of the JSON status property will not show any issue making error detection more difficult.

---

To reproduce, follow the below steps.

1. On the source environment create a node that supports child ordering (e.g., sling:OrderedFolder)
   For example, /content/dam/test/folderA. The source will have other folders and assets in /content/dam/test in such a way that the sync takes a few minutes.
2. On the target environment create a node with the same name in the same path (/content/dam/test/folderA) that does not support child ordering (e.g., sling:Folder)
3. Use "vlt rcp" via json/http interface to copy from the source to the target server the top-level folder (e.g. /content/dam/test):

• create task
• start task
• get info of task progress a few times

Options when task is created:

• update: true
• onlyNewer: true
• recursive: true
• noOrdering: false
• throttle: 1
• batchsize: 2048

Expected result:

• all nodes are synchronised successfully
• if an issue occurs (on folderA), when making a call to get info of the task progress, the JSON returned should have a new "state" ERROR to indicate that a problem occurred during processing

Actual result:

• All nodes that should be processed after folderA are not actually synchronised onto the target server.
• When making a call to get info of the task progress, the JSON returned has a "state" ENDED and HTTP code is 200, therefore there is no way of knowing that a problem occurred when synchronising large amounts of data unless logs are being checked regularly. This may hinder automation whereby a sync task would run regularly on a schedule and we would like the error to be raised at the level where the call is being made.