Ah, Thanks. The "test application" setting I have missed.

Now I have to wait some hours for the download to be finished.

So far, I noticed on ATM tasks an abnormal progress notification.
Progress usually jumped from 0% to 0.199% in a short first step, and then directly to 100% in a second long step, staying so until task completion.
Along this second step, estimated time remaining was not shown ( "---" shown instead)

Example of wrong progress notification:
CDK2_29_26_5-QUICO_ATM_OFF_STEPS-2-5-RND5867_0




Today, I catched two ATM tasks showing a linear progression and accurate estimated time remaining.
At this moment, both of them are still in progress.

Examples of right progress notification:
Tyk2_jmc_23_jmc_27_2-QUICO_ATM_OFF12_STEPS-0-5-RND0292_2




Tyk2_jmc_23_ejm_55_5-QUICO_ATM_OFF12_STEPS-0-5-RND1896_3

There is still a mix of old, broken progress tasks along with fixed progress tasks in rotation.

Just depends on whether you get a new _0 or an older _x wingman task.

No, it's not the replication number.

The clue is in the task name: one with "STEPS-0-5" will show normal progress, one with any other "STEPS-n-5" will jump quickly to 100%.

The old, very long running, tasks processed 341 samples all in one go. The new shorter ones have been split into five shorter runs, processing 70 samples each (confusingly numbered 0 to 4 - I've never seen a 'steps-5-5').

Number zero - the first in the chain - processes samples 1 to 70, which is what the progress display expects. The second processes samples 71 to 140 - so it starts beyond the finishing point. And so on.

Nice explanation.
This makes full sense to that behavior.