[QA] Fail api test while checking status code

[prashant-gurung899]

The following scenario has been failing frequently with status code check failure: Check builds: https://ci.opencloud.eu/repos/3/pipeline/585/487 https://ci.opencloud.eu/repos/3/pipeline/582/505 https://ci.opencloud.eu/repos/3/pipeline/580/505

Scenario Outline: send last chunk twice                                                                                   # /woodpecker/src/github.com/opencloud-eu/opencloud/tests/acceptance/features/coreApiWebdavUploadTUS/lowLevelUpload.feature:45
    Given using <dav-path-version> DAV path                                                                                 # FeatureContext::usingOldOrNewOrSpacesDavPath()
    And user "Alice" has created a new TUS resource on the WebDAV API with these headers:                                   # TUSContext::userHasCreatedNewTUSResourceWithHeaders()
      | Upload-Length   | 10                    |
      | Upload-Metadata | filename ZmlsZS50eHQ= |
    When user "Alice" sends a chunk to the last created TUS Location with offset "0" and data "123" using the WebDAV API    # TUSContext::userSendsAChunkToTUSLocationWithOffsetAndData()
    And user "Alice" sends a chunk to the last created TUS Location with offset "3" and data "4567890" using the WebDAV API # TUSContext::userSendsAChunkToTUSLocationWithOffsetAndData()
    And user "Alice" sends a chunk to the last created TUS Location with offset "3" and data "0000000" using the WebDAV API # TUSContext::userSendsAChunkToTUSLocationWithOffsetAndData()
    Then the HTTP status code should be "404"                                                                               # FeatureContext::thenTheHTTPStatusCodeShouldBe()
    And the content of file "/file.txt" for user "Alice" should be "1234567890"                                             # FeatureContext::contentOfFileForUserShouldBe()

    Examples:
      | dav-path-version |
      | old              |
      | new              |
      | spaces           |
        Failed step: Then the HTTP status code should be "404"
        HTTP status code 409 is not the expected value 404
        Failed asserting that 409 matches expected '404'.

Also listed here: https://github.com/opencloud-eu/qa/issues/50

CC @individual-it @ScharfViktor

[individual-it]

Here what the TUS protocol description says:

... The Upload-Offset header’s value MUST be equal to the current offset of the resource. In order to achieve parallel upload the Concatenation extension MAY be used. If the offsets do not match, the Server MUST respond with the 409 Conflict status without modifying the upload resource. ... If the server receives a PATCH request against a non-existent resource it SHOULD return a 404 Not Found status.

Here my guess what happens:

1. TUS resource is created
2. first chunk is send => 204
3. second chunk is send => 204
4. mostly the server is fast enough, deletes the TUS resource and replies correctly with 404, but sometimes the TUS resource still exists and then the server replies with 409

not sure who knows about that codepath @rhafer @micbar @aduffeck , do you think the assumption above is correct? If so I would suggest to accept both 404 and 409 in this test. Alternatively we could wait and retry till eventually 404 is returned because the resource does not exist anymore