I am writing a corb task where the uri module passes on to the processor module a list of uris of documents of which the string value of a certain element has to be padded. The uri module lists those documents where the strings are shorter than desired. Since after the updates the strings would be of desired length the changed documents can't be identified any more. Also there would not be any record of the previous lengths of the strings in those documents. So, I don't see an easy way of writing a roll-back script.
What is an efficient way of doing rollback for such scenarios?
We don't have version managed documents.
What about tagging all the changed documents with a collection that represents the CoRB batch?
Once you know they're all new you can simply call xdmp:collection-delete. If you need finer-grained data you can add that as part of each update, either in the document or in the properties. Basically you'd save the rollback information as you touch each document. Don't try to keep rollback information for an entire batch in a single document, because every CoRB threads will want to update it at the same time.
This approach means you'd have to supply the batch id somehow. I'd probably encode it directly into the shortest possible CoRB XQuery module. I'd write a library module with functions that do everything important for the batch work. Then a simple shell script could write out a new main module for each batch job, with the batch id encoded directly into the XQuery. That main module would define $URI for CoRB, import the library, and call a function: something like mylib:batch-operation($URI, "batch-"||1234567). The shell script would provide that batch-id: epoch seconds when the batch began, or whatever makes sense to you.
You might also take a look at https://github.com/mblakele/taskbot and see if it gives you more flexibility.