[tests-only][full-ci] added test to restart and resume all stale uploads

[PrajwolAmatya]

Description

This PR adds test to restart and resume all the stale uploads using the CLI commands.

ocis storage-users uploads sessions --resume
ocis storage-users uploads sessions --restart

Currently the CLI command does not restart or resume any uploads are returns empty list, reported in #11296.

Related Issue

• Part of: [QA] [CLI] Add cli test coverage for managing unifinished upload using storage-user #11274
• Bug Report: [CLI] Restart and Resume stale uploads returns empty list #11296

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:

[prashant-gurung899]

LGTM 👍

[amrita-shrestha]

Why are you using this step ? IMO you are testing resume command?

[amrita-shrestha]

An unfinished upload and a stale upload are different things. I have created a stale upload by deleting the .info file, and I doubt it is possible to resume/restart the upload file from which the .info file has been deleted.

[PrajwolAmatya]

That could be the reason why the table in the response is empty. Maybe resume and restart is not possible for stale uploads.

[amrita-shrestha]

in previous merged PR, i have doubt

 Scenario: restart upload sessions that are in postprocessing
    Given user "Alice" has uploaded file with content "upload content" to "/file1.txt"
    And the config "POSTPROCESSING_DELAY" has been set to "10s"
    And user "Alice" has uploaded file with content "upload content" to "/file2.txt" 
    When the administrator restarts the upload sessions that are in postprocessing 
    Then the command should be successful
    And the CLI response should contain these entries:
      | file2.txt |
    And the CLI response should not contain these entries:
      | file1.txt |

seems not full proof because upload can finish in between getting uploadid and restarting upload

[PrajwolAmatya]

seems not full proof because upload can finish in between getting uploadid and restarting upload

If a file is listed in the response of the command then it confirms the command worked successfully as these commands are meant to output the list of uploads that match the criteria provided in the command.

[amrita-shrestha]

seems not full proof because upload can finish in between getting uploadid and restarting upload

If a file is listed in the response of the command then it confirms the command worked successfully as these commands are meant to output the list of uploads that match the criteria provided in the command.

still not 100% guarnteed that it will never show flakiness

[PrajwolAmatya]

still not 100% guarnteed that it will never show flakiness

I didn't get it, how this can be flaky?

[amrita-shrestha]

still not 100% guarnteed that it will never show flakiness

I didn't get it, how this can be flaky?

ok try it manually. List unfinished uploads and restart that . Again, run the CLI command to restart the same resource. What will be the output: its fail or pass?

[PrajwolAmatya]

still not 100% guarnteed that it will never show flakiness

I didn't get it, how this can be flaky?

ok try it manually. List unfinished uploads and restart that . Again, run the CLI command to restart the same resource. What will be the output: its fail or pass?

If we again restart the upload of same resource it will restart the upload process of that resource again.

I think this PR is not the right place to discuss this.

We should find the answer for the following point.

An unfinished upload and a stale upload are different things. I have created a stale upload by deleting the .info file, and I doubt it is possible to resume/restart the upload file from which the .info file has been deleted.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud