[
https://issues.apache.org/jira/browse/JCRVLT-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544363#comment-17544363
]
Konrad Windszus commented on JCRVLT-633:
----------------------------------------
[~irinachirita] Thanks for the report, can you come up with a PR containing a
fix?
> VLT RCP doesn't fail task when child node ordering error occurs
> ---------------------------------------------------------------
>
> Key: JCRVLT-633
> URL: https://issues.apache.org/jira/browse/JCRVLT-633
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: RCP
> Affects Versions: 3.5.6
> Reporter: Irina Chirita
> Priority: Major
>
> 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.
> # 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.
> # 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)
> # 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.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
