Restoring a file with Oracle, checksum is not restored

[phil-davis]

Run the acceptance tests with Oracle database. (see PR #37025 )
https://drone.owncloud.com/owncloud/core/23587/57/13

  Scenario: Restore a file and check, if the content and correct checksum is now in the current file                                                                                          # /drone/src/tests/acceptance/features/apiVersions/fileVersions.feature:132
    Given user "user0" has uploaded file with content "AAAAABBBBBCCCCC" and checksum "MD5:45a72715acdd5019c5be30bdbb75233e" to "/davtest.txt"                                                 # ChecksumContext::userHasUploadedFileWithContentAndChecksumToUsingTheAPI()
    And user "user0" has uploaded file "filesForUpload/textfile.txt" to "/davtest.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a"                                                   # ChecksumContext::userHasUploadedFileToWithChecksumUsingTheAPI()
    And the version folder of file "/davtest.txt" for user "user0" should contain "1" element                                                                                                 # FilesVersionsContext::theVersionFolderOfFileShouldContainElements()
    When user "user0" restores version index "1" of file "/davtest.txt" using the WebDAV API                                                                                                  # FilesVersionsContext::userRestoresVersionIndexOfFile()
    Then the content of file "/davtest.txt" for user "user0" should be "AAAAABBBBBCCCCC"                                                                                                      # FeatureContext::contentOfFileForUserShouldBe()
    And as user "user0" the webdav checksum of "/davtest.txt" via propfind should match "SHA1:acfa6b1565f9710d4d497c6035d5c069bd35a8e8 MD5:45a72715acdd5019c5be30bdbb75233e ADLER32:1ecd03df" # ChecksumContext::theWebdavChecksumOfViaPropfindShouldMatch()
      Expected: webDav checksum should be SHA1:acfa6b1565f9710d4d497c6035d5c069bd35a8e8 MD5:45a72715acdd5019c5be30bdbb75233e ADLER32:1ecd03df but got SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f MD5:d70b40f177b14b470d1756a3c12b963a ADLER32:8ae90960
      Failed asserting that two strings are equal.
      --- Expected
      +++ Actual
      @@ @@
      -'SHA1:acfa6b1565f9710d4d497c6035d5c069bd35a8e8 MD5:45a72715acdd5019c5be30bdbb75233e ADLER32:1ecd03df'
      +'SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f MD5:d70b40f177b14b470d1756a3c12b963a ADLER32:8ae90960'

--- Failed scenarios:

    /drone/src/tests/acceptance/features/apiVersions/fileVersions.feature:132

37 scenarios (36 passed, 1 failed)
428 steps (427 passed, 1 failed)

Nothing is seen in owncloud.log

This scenario passes with other databases (MySQL, MariaDB and PostgreSQL of all supported versions) Investigate...

[phil-davis]

I added QA-team label for us to first investigate this failure a bit and provide more feedback on what happens.

[phil-davis]

I suggest that we add some acceptance tests with Oracle to the drone CI.
First we could add just the apiVersions acceptance test suite. Run it and verify that this still fails.
Then @skipOnOracle the failing scenario, and add a scenario that demonstrates what happens on Oracle. Tag that scenario @skip @issue-37026

Then I think we can have 1 pipeline that runs apiVersions with ~@skipOnOracle tag - that will run all the scenarios expect the skipOnOracle scenario, to show that they are passing.

And another pipeline that runs @skip&&@issue-37026 which specifically runs the 1 scenario that is special for Oracle.

(or some other idea for how to have this running in CI)

[phil-davis]

Acceptance test scenario has been added to CI in PR #37296
I will remove QA assignment. This is now an issue to be looked at by developers.

[phil-davis]

The scenario that runs on Oracle to demonstrate the problem seems to be "failing" intermittently. Sometimes the checksums returned are actually the correct checksums of the restored file - i.e. the bug is not there. So maybe this "bug" is actually a timing thing and happens on Oracle because Oracle is slow? or?

e.g. https://drone.owncloud.com/owncloud/core/24495/83/13

  @skipOnStorage:ceph @skipOnStorage:scality @files_primary_s3-issue-156 @skipOnOcis @issue-ocis-reva-57 @skip @issue-37026
  Scenario: Restore a file and check, if the content and correct checksum is now in the current file                                                                                          # /drone/src/tests/acceptance/features/apiVersions/fileVersions.feature:143
    Given user "user0" has uploaded file with content "AAAAABBBBBCCCCC" and checksum "MD5:45a72715acdd5019c5be30bdbb75233e" to "/davtest.txt"                                                 # ChecksumContext::userHasUploadedFileWithContentAndChecksumToUsingTheAPI()
    And user "user0" has uploaded file "filesForUpload/textfile.txt" to "/davtest.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a"                                                   # ChecksumContext::userHasUploadedFileToWithChecksumUsingTheAPI()
    And the version folder of file "/davtest.txt" for user "user0" should contain "1" element                                                                                                 # FilesVersionsContext::theVersionFolderOfFileShouldContainElements()
    When user "user0" restores version index "1" of file "/davtest.txt" using the WebDAV API                                                                                                  # FilesVersionsContext::userRestoresVersionIndexOfFile()
    Then the content of file "/davtest.txt" for user "user0" should be "AAAAABBBBBCCCCC"                                                                                                      # FeatureContext::contentOfFileForUserShouldBe()
    And as user "user0" the webdav checksum of "/davtest.txt" via propfind should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f MD5:d70b40f177b14b470d1756a3c12b963a ADLER32:8ae90960" # ChecksumContext::theWebdavChecksumOfViaPropfindShouldMatch()
      Expected: webDav checksum should be SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f MD5:d70b40f177b14b470d1756a3c12b963a ADLER32:8ae90960 but got SHA1:acfa6b1565f9710d4d497c6035d5c069bd35a8e8 MD5:45a72715acdd5019c5be30bdbb75233e ADLER32:1ecd03df
      Failed asserting that two strings are equal.
      --- Expected
      +++ Actual
      @@ @@
      -'SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f MD5:d70b40f177b14b470d1756a3c12b963a ADLER32:8ae90960'
      +'SHA1:acfa6b1565f9710d4d497c6035d5c069bd35a8e8 MD5:45a72715acdd5019c5be30bdbb75233e ADLER32:1ecd03df'

--- Failed scenarios:

    /drone/src/tests/acceptance/features/apiVersions/fileVersions.feature:143

1 scenario (1 failed)
9 steps (8 passed, 1 failed)
0m21.55s (14.93Mb)

The scenario is being removed from regular CI runs - PR #37312

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed.

[phil-davis]

This was auto-closed. Opening again. I will check if this is still a problem with Oracle...

[phil-davis]

I made PR #39755 to double-check current test results on Oracle.

[phil-davis]

https://drone.owncloud.com/owncloud/core/34552/85/13

  Scenario: Restore a file and check, if the content and correct checksum is now in the current file                                                                                          # /drone/src/tests/acceptance/features/apiVersions/fileVersions.feature:115
    Given user "Alice" has uploaded file with content "AAAAABBBBBCCCCC" and checksum "MD5:45a72715acdd5019c5be30bdbb75233e" to "/davtest.txt"                                                 # ChecksumContext::userHasUploadedFileWithContentAndChecksumToUsingTheAPI()
    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/davtest.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a"                                                   # ChecksumContext::userHasUploadedFileToWithChecksumUsingTheAPI()
    And the version folder of file "/davtest.txt" for user "Alice" should contain "1" element                                                                                                 # FilesVersionsContext::theVersionFolderOfFileShouldContainElements()
    When user "Alice" restores version index "1" of file "/davtest.txt" using the WebDAV API                                                                                                  # FilesVersionsContext::userRestoresVersionIndexOfFile()
    Then the content of file "/davtest.txt" for user "Alice" should be "AAAAABBBBBCCCCC"                                                                                                      # FeatureContext::contentOfFileForUserShouldBe()
    And as user "Alice" the webdav checksum of "/davtest.txt" via propfind should match "SHA1:acfa6b1565f9710d4d497c6035d5c069bd35a8e8 MD5:45a72715acdd5019c5be30bdbb75233e ADLER32:1ecd03df" # ChecksumContext::theWebdavChecksumOfViaPropfindShouldMatch()

The version-restore scenario passes on Oracle nowadays. This issue has been fixed at some time.

The test refactoring has been merged to master in PR #39757