Bump reva deps #8412

butonic · 2024-02-08T16:44:48Z

bump all the deps!

and make tusd CORS headers configurable, see cs3org/reva#4507

update-docs · 2024-02-08T16:44:52Z

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

vendor/go-micro.dev/v4/api/options.go

micbar

Did a review of the vendor folder.

Changes are looking good.

Please clarify that the go-micro client and Registry changes are already used in ocis.

If that is correct, ok from my side.

butonic · 2024-02-19T12:36:53Z

I see an error when stopping a large upload:

{"level":"error","service":"frontend","pkg":"rhttp","traceid":"3c99e006acb683d3b43313b520b7b542","request-id":"37c1b3bc-a36f-4dfa-8d33-68eee87cb3c1","error":"Patch \"http://localhost:9158/data/tus/335e922d-c994-4eec-b4e3-65d988d2811f\": context canceled","time":"2024-02-19T13:34:00+01:00","message":"error doing PATCH request to data service"}
{"level":"error","service":"storage-users","pkg":"rhttp","traceid":"03e9501a2ea3a36c382d32549a4e704a","host":"127.0.0.1","method":"PATCH","uri":"/data/tus/335e922d-c994-4eec-b4e3-65d988d2811f","url":"/335e922d-c994-4eec-b4e3-65d988d2811f","proto":"HTTP/1.1","status":500,"size":15,"start":"19/Feb/2024:13:33:58 +0100","end":"19/Feb/2024:13:34:00 +0100","time_ns":1144378976,"time":"2024-02-19T13:34:00+01:00","message":"http"}
{"level":"error","service":"frontend","pkg":"rhttp","traceid":"3c99e006acb683d3b43313b520b7b542","host":"127.0.0.1","method":"PATCH","uri":"/data/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJyZXZhIiwiZXhwIjoxNzA4NDMyMzgwLCJpYXQiOjE3MDgzNDU5ODAsInRhcmdldCI6Imh0dHA6Ly9sb2NhbGhvc3Q6OTE1OC9kYXRhL3R1cy8zMzVlOTIyZC1jOTk0LTRlZWMtYjRlMy02NWQ5ODhkMjgxMWYifQ.b6i-_kih05jLbuc_FIdfmORMJ76lignlOmoZvQTucdU","url":"/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJyZXZhIiwiZXhwIjoxNzA4NDMyMzgwLCJpYXQiOjE3MDgzNDU5ODAsInRhcmdldCI6Imh0dHA6Ly9sb2NhbGhvc3Q6OTE1OC9kYXRhL3R1cy8zMzVlOTIyZC1jOTk0LTRlZWMtYjRlMy02NWQ5ODhkMjgxMWYifQ.b6i-_kih05jLbuc_FIdfmORMJ76lignlOmoZvQTucdU","proto":"HTTP/1.1","status":500,"size":0,"start":"19/Feb/2024:13:33:58 +0100","end":"19/Feb/2024:13:34:00 +0100","time_ns":1145671040,"time":"2024-02-19T13:34:00+01:00","message":"http"}
{"level":"error","service":"frontend","pkg":"rhttp","traceid":"8851badfc7074bd0921755e09113ca90","host":"127.0.0.1","method":"DELETE","uri":"/data/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJyZXZhIiwiZXhwIjoxNzA4NDMyMzgwLCJpYXQiOjE3MDgzNDU5ODAsInRhcmdldCI6Imh0dHA6Ly9sb2NhbGhvc3Q6OTE1OC9kYXRhL3R1cy8zMzVlOTIyZC1jOTk0LTRlZWMtYjRlMy02NWQ5ODhkMjgxMWYifQ.b6i-_kih05jLbuc_FIdfmORMJ76lignlOmoZvQTucdU","url":"/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJyZXZhIiwiZXhwIjoxNzA4NDMyMzgwLCJpYXQiOjE3MDgzNDU5ODAsInRhcmdldCI6Imh0dHA6Ly9sb2NhbGhvc3Q6OTE1OC9kYXRhL3R1cy8zMzVlOTIyZC1jOTk0LTRlZWMtYjRlMy02NWQ5ODhkMjgxMWYifQ.b6i-_kih05jLbuc_FIdfmORMJ76lignlOmoZvQTucdU","proto":"HTTP/1.1","status":501,"size":0,"start":"19/Feb/2024:13:34:01 +0100","end":"19/Feb/2024:13:34:01 +0100","time_ns":103835,"time":"2024-02-19T13:34:01+01:00","message":"http"}

butonic · 2024-02-19T13:40:46Z

the 501 on delete is fixed with cs3org/reva#4527

butonic · 2024-02-19T15:19:30Z

It seems that was not the problem.

The failing web test:

1) Scenario: uploading a big file (when chunking is implemented this upload should be chunked) (attempt 1, retried) # features/webUIUpload/upload.feature:87
   ✔ Before # setup.js:38
   ✔ Before # setup.js:42
   ✔ Before # setup.js:53
   ✔ Before # setup.js:60
   ✔ Before # setup.js:71
   ✔ Before # stepDefinitions/filesContext.js:17
   ✔ Before # stepDefinitions/generalContext.js:149
   ✔ Before # stepDefinitions/generalContext.js:187
   ✔ Before # stepDefinitions/middlewareContext.js:46
   ✔ Given user "Alice" has been created with default attributes and without skeleton files in the server # stepDefinitions/middlewareContext.js:66
   ✔ And user "Alice" has created folder "simple-folder" in the server # stepDefinitions/middlewareContext.js:66
   ✔ And user "Alice" has uploaded file with content "initial content" to "lorem.txt" in the server # stepDefinitions/middlewareContext.js:66
   ✔ And user "Alice" has uploaded file with content "initial content" to "simple-folder/lorem.txt" in the server # stepDefinitions/middlewareContext.js:66
   ✔ And user "Alice" has logged in using the webUI # stepDefinitions/loginContext.js:68
   ✔ Given a file with the size of "30000000" bytes and the name "big-video.mp4" has been created locally in the middleware # stepDefinitions/middlewareContext.js:66
   ✔ When the user uploads a created file "big-video.mp4" using the webUI # stepDefinitions/filesContext.js:215
   ✔ Then no message should be displayed on the webUI # stepDefinitions/generalContext.js:70
   ✖ And file "big-video.mp4" should be listed on the webUI # stepDefinitions/filesContext.js:372
       AssertionError [ERR_ASSERTION]: An error occurred while running .getText() command on <//span[contains(@class, "oc-resource-name") and (@data-test-resource-name='big-video.mp4' or @data-test-resource-path='/big-video.mp4') and @data-test-resource-type='file']>: 
           at Proxy.checkFileName (/drone/src/webTestRunner/tests/acceptance/pageObjects/FilesPageElement/filesList.js:401:16)
           at processTicksAndRejections (node:internal/process/task_queues:95:5)
           at Proxy.waitForFileVisible (/drone/src/webTestRunner/tests/acceptance/pageObjects/FilesPageElement/filesList.js:379:7)
   - And as "Alice" the content of "big-video.mp4" in the server should be the same as the content of local file "big-video.mp4" # stepDefinitions/middlewareContext.js:66
   ✔ After # stepDefinitions/middlewareContext.js:60
   ✔ After # stepDefinitions/generalContext.js:205
   ✔ After # stepDefinitions/generalContext.js:174
   ✔ After # stepDefinitions/generalContext.js:115
   ✔ After # setup.js:104
   ✔ After # setup.js:100
   ✔ After # setup.js:96
   ✔ After # setup.js:89
   ✔ After # setup.js:80

But locally I cannot reporduce ... is the upload maybe too slow?

ScharfViktor · 2024-02-19T16:10:00Z

But locally I cannot reporduce ... is the upload maybe too slow?

I could reproduce it:

uploading file less than 10 mb - works
uploading file more than 10 mb fails

How reproduce:

switch to branch bump-reva-deps
make -C ocis clean generate build
start ocis binary
upload file more than 10Mb

Actual:

Screen.Recording.2024-02-19.at.17.07.32.mov

ocis log: OCIS_LOG_LEVEL=debug

2024/02/19 17:07:39 http: TLS handshake error from [::1]:60182: remote error: tls: unknown certificate
2024-02-19T17:07:39+01:00 DBG rewrite hook found line=/Users/scharfviktor/Work/ocis/services/proxy/pkg/router/router.go:224 method=PATCH path=/data/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJyZXZhIiwiZXhwIjoxNzA4NDQ1MjU5LCJpYXQiOjE3MDgzNTg4NTksInRhcmdldCI6Imh0dHA6Ly9sb2NhbGhvc3Q6OTE1OC9kYXRhL3R1cy9lOWRhYWIzYy03YWVjLTQxMzUtOTU5NC01NWUwNzNlMzMyZjEifQ.PPiw28uNt0UIljGDioesLwp-Ax-sWUekOaMbHPKPE4U policy=ocis prefix=/data routeType=prefix service=proxy
2024-02-19T17:07:39+01:00 INF skipping auth check for: /data/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJyZXZhIiwiZXhwIjoxNzA4NDQ1MjU5LCJpYXQiOjE3MDgzNTg4NTksInRhcmdldCI6Imh0dHA6Ly9sb2NhbGhvc3Q6OTE1OC9kYXRhL3R1cy9lOWRhYWIzYy03YWVjLTQxMzUtOTU5NC01NWUwNzNlMzMyZjEifQ.PPiw28uNt0UIljGDioesLwp-Ax-sWUekOaMbHPKPE4U line=/Users/scharfviktor/Work/ocis/vendor/github.com/cs3org/reva/v2/internal/http/interceptors/auth/auth.go:195 pkg=rhttp service=frontend traceid=b4a4ce5b918bfd7909b811e4a6bf2fcf

saw-jan · 2024-02-20T03:33:59Z

And there is this error log

{"level":"error","service":"frontend","pkg":"rhttp","traceid":"16995d691cd01911e970ca91f8fa40ee","request-id":"766dcb17-c21b-4f97-98ae-56b1a7ad572a","content-length":24493475,"transferred-bytes":0,"time":"2024-02-20T09:16:28+05:45","message":"content length vs transferred bytes mismatch"}
{"level":"error","service":"frontend","pkg":"rhttp","traceid":"6479db37bf424506b2915d322c6a6e39","request-id":"b6c4aa22-8378-442e-b12d-8696764e0dc6","content-length":24493475,"transferred-bytes":0,"time":"2024-02-20T09:16:28+05:45","message":"content length vs transferred bytes mismatch"}

butonic · 2024-02-20T08:08:47Z

@saw-jan hm those lines are now logged by the datagateway in the frontent service when the content length does not match the actual body length:

	if httpRes.Header.Get("Content-Length") != "" {
		i, err := strconv.ParseInt(httpRes.Header.Get("Content-Length"), 10, 64)
		if err != nil {
			log.Error().Err(err).Str("content-length", httpRes.Header.Get("Content-Length")).Msg("invalid content length in dataprovider response")
		}
		if i != c {
			log.Error().Int64("content-length", i).Int64("transferred-bytes", c).Msg("content length vs transferred bytes mismatch")
		}
	}

But good hint!

I thought maybe I missed the make -C ocis clean generate build step ... but I don't get a 403 Forbidden. I need to check if I set an env var that affects this, because I have a differnt domain configured, which also sets CORS headers ...

👀

butonic · 2024-02-20T10:03:56Z

I accidentially checked in my domain as the CORS allowed origin for tus uploads. Changed it to * as all the other CORS allow origin defaults.

butonic · 2024-02-20T10:50:47Z

I assume these failures are caused by disableing resharing in the sharing manager:


  Scenario: sharing parent folder to user with all permissions and its child folder to group with read permission then check reshare operation # /drone/src/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:265

    Given group "grp1" has been created                                                                                                        # FeatureContext::groupHasBeenCreated()

    And user "Carol" has been created with default attributes and without skeleton files                                                       # FeatureContext::userHasBeenCreatedWithDefaultAttributes()

    And user "Carol" has created the following folders                                                                                         # FeatureContext::userHasCreatedFollowingFolders()

      | path                  |

      | /parent               |

      | /parent/child1        |

      | /parent/child1/child2 |

    And user "Alice" has been added to group "grp1"                                                                                            # FeatureContext::userHasBeenAddedToGroup()

    And user "Brian" has been added to group "grp1"                                                                                            # FeatureContext::userHasBeenAddedToGroup()

    And user "Carol" has created a share with settings                                                                                         # FeatureContext::userHasCreatedAShareWithSettings()

      | path        | /parent |

      | shareType   | user    |

      | shareWith   | Brian   |

      | permissions | all     |

    And user "Carol" has created a share with settings                                                                                         # FeatureContext::userHasCreatedAShareWithSettings()

      | path        | /parent/child1 |

      | shareType   | group          |

      | shareWith   | grp1           |

      | permissions | read           |

    When user "Brian" creates a share using the sharing API with settings                                                                      # FeatureContext::userCreatesAShareWithSettings()

      | path        | /Shares/parent |

      | shareType   | user           |

      | shareWith   | Alice          |

      | permissions | read           |

    Then the HTTP status code should be "200"                                                                                                  # FeatureContext::thenTheHTTPStatusCodeShouldBe()

    And the OCS status code should be "100"                                                                                                    # OCSContext::theOCSStatusCodeShouldBe()

      OCS status code is not any of the expected values 100 got 104

      Failed asserting that an array contains '104'.

    And as "Brian" folder "/Shares/child1" should exist                                                                                        # FeatureContext::asFileOrFolderShouldExist()

    And as "Alice" folder "/Shares/child1" should exist                                                                                        # FeatureContext::asFileOrFolderShouldExist()

    And as "Alice" folder "/Shares/parent" should exist                                                                                        # FeatureContext::asFileOrFolderShouldExist()

So I changed it to enabled again.

AFAICT the testsuite uses all in the permissions ... which is different when using disabling resharing, because then the sharing permission (16) cannot be granted.

Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>

butonic · 2024-02-20T11:27:07Z

looking into this:

 @issue-1233
  Scenario Outline: get a share with a user that didn't receive the share                # /drone/src/tests/acceptance/features/coreApiShareOperationsToShares1/gettingShares.feature:134
    Given using OCS API version "<ocs_api_version>"                                      # FeatureContext::usingOcsApiVersion()
    And user "Carol" has been created with default attributes and without skeleton files # FeatureContext::userHasBeenCreatedWithDefaultAttributes()
    And user "Alice" has uploaded file with content "some data" to "/textfile0.txt"      # FeatureContext::userHasUploadedAFileWithContentTo()
    And user "Alice" has shared file "textfile0.txt" with user "Brian"                   # FeatureContext::userHasSharedFileWithUserUsingTheSharingApi()
    When user "Carol" gets the info of the last share using the sharing API              # FeatureContext::userGetsInfoOfLastShareUsingTheSharingApi()
    Then the OCS status code should be "404"                                             # OCSContext::theOCSStatusCodeShouldBe()
    And the HTTP status code should be "<http_status_code>"                              # FeatureContext::thenTheHTTPStatusCodeShouldBe()

    Examples:
      | ocs_api_version | http_status_code |
      | 1               | 200              |
        Failed step: Then the OCS status code should be "404"
        OCS status code is not any of the expected values 404 got 998
        Failed asserting that an array contains '998'.
      | 2               | 404              |
        Failed step: Then the OCS status code should be "404"
        OCS status code is not any of the expected values 404 got 998
        Failed asserting that an array contains '998'.

ScharfViktor · 2024-02-20T11:50:41Z

looking into this:

this test is in expected failures file, do you want to fix it too?

I see that another tests is reason the failed CI. (where we get 104 instead of 100)
If you need helping with test debug, just ping me

saw-jan · 2024-02-20T12:03:21Z

Yeah, the failure is during creating share/reshare

    And user "Carol" has been added to group "grp1" 
    And user "Alice" has shared folder "common" with group "grp1" 
    And user "Alice" has shared file "textfile0.txt" with user "Carol"
      OCS status code is not any of the expected values 100,200 got 104
      Failed asserting that an array contains '104'.

And AFAIK, 104 means something doesn't exit

butonic · 2024-02-20T12:10:13Z

🤦‍♂️ damn looking at the wrong test ...

butonic · 2024-02-20T12:11:40Z

looking at coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:474

@issue-764 @issue-7555
Scenario: share a file by multiple channels and download from sub-folder and direct file share                          # /drone/src/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:474
  Given these users have been created with default attributes and without skeleton files:                               # FeatureContext::theseUsersHaveBeenCreatedWithDefaultAttributesAndWithoutSkeletonFiles()
    | username |
    | Brian    |
    | Carol    |
  And group "grp1" has been created                                                                                     # FeatureContext::groupHasBeenCreated()
  And user "Brian" has been added to group "grp1"                                                                       # FeatureContext::userHasBeenAddedToGroup()
  And user "Carol" has been added to group "grp1"                                                                       # FeatureContext::userHasBeenAddedToGroup()
  And user "Alice" has created folder "/common"                                                                         # FeatureContext::userHasCreatedFolder()
  And user "Alice" has created folder "/common/sub"                                                                     # FeatureContext::userHasCreatedFolder()
  And user "Alice" has uploaded file with content "ownCloud" to "/textfile0.txt"                                        # FeatureContext::userHasUploadedAFileWithContentTo()
  And user "Alice" has shared folder "common" with group "grp1"                                                         # FeatureContext::userHasSharedFileWithGroupUsingTheSharingApi()
  And user "Alice" has shared file "textfile0.txt" with user "Carol"                                                    # FeatureContext::userHasSharedFileWithUserUsingTheSharingApi()
    OCS status code is not any of the expected values 100,200 got 104
    Failed asserting that an array contains '104'.
  And user "Alice" has moved file "/textfile0.txt" to "/common/textfile0.txt"                                           # FeatureContext::userHasMovedFile()
  And user "Alice" has moved file "/common/textfile0.txt" to "/common/sub/textfile0.txt"                                # FeatureContext::userHasMovedFile()
  When user "Carol" uploads file "filesForUpload/file_to_overwrite.txt" to "/Shares/textfile0.txt" using the WebDAV API # FeatureContext::userUploadsAFileToUsingWebDavApi()
  Then the HTTP status code should be "204"                                                                             # FeatureContext::thenTheHTTPStatusCodeShouldBe()
  And the content of file "/Shares/common/sub/textfile0.txt" for user "Carol" should be "BLABLABLA" plus end-of-line    # FeatureContext::contentOfFileForUserShouldBePlusEndOfLine()
  And the content of file "/Shares/textfile0.txt" for user "Carol" should be "BLABLABLA" plus end-of-line               # FeatureContext::contentOfFileForUserShouldBePlusEndOfLine()
  And user "Carol" should see the following elements                                                                    # FeatureContext::userShouldSeeTheElements()
    | /Shares/common/sub/textfile0.txt |
    | /Shares/textfile0.txt            |
  And the content of file "/Shares/common/sub/textfile0.txt" for user "Brian" should be "BLABLABLA" plus end-of-line    # FeatureContext::contentOfFileForUserShouldBePlusEndOfLine()
  And the content of file "/common/sub/textfile0.txt" for user "Alice" should be "BLABLABLA" plus end-of-line           # FeatureContext::contentOfFileForUserShouldBePlusEndOfLine()

butonic · 2024-02-20T12:21:09Z

@saw-jan hm 104 means forbidden. At least that is what it should mean:

// MetaForbidden is an error response with code 104
var MetaForbidden = Meta{Status: "", StatusCode: 104, Message: "Forbidden"}

But I ran into #1233 which expects an OCS 404 status for a non existing share, which IMNSHO should be an OCS 998 status ... but OCS is lagacy, so ... whatever. Aligned to be as broken as oc10 with cs3org/reva#4529

Digging further into the wrong Create response...

butonic · 2024-02-20T12:34:15Z

There is a bug when creating shares ... we still add the share permission somewhere ... 👀

Hm no ... currently resharing is enabled by default

butonic · 2024-02-20T14:11:10Z

The error we get on the OCS API is

// MessageShareExists is used when a user tries to create a new share for the same user
var MessageShareExists = "A share for the recipient already exists"
``

which is only used when the Share() call returns an ALREADY_EXISTS code:
```go
	createShareResponse, err := client.CreateShare(ctx, req)
	if err != nil {
		return nil, &ocsError{
			Code:    response.MetaServerError.StatusCode,
			Message: "error sending a grpc create share request",
			Error:   err,
		}
	}
	if createShareResponse.Status.Code != rpc.Code_CODE_OK {
		logger.Debug().Interface("Code", createShareResponse.Status.Code).Str("message", createShareResponse.Status.Message).Msg("grpc create share request failed")
		switch createShareResponse.Status.Code {
		case rpc.Code_CODE_NOT_FOUND:
			return nil, &ocsError{
				Code:    response.MetaNotFound.StatusCode,
				Message: "not found",
				Error:   nil,
			}
		case rpc.Code_CODE_ALREADY_EXISTS:
			return nil, &ocsError{
				Code:    response.MetaForbidden.StatusCode,
				Message: response.MessageShareExists,
				Error:   nil,
			}
 // ...
```

But why would it already exist ...

butonic · 2024-02-20T14:13:02Z

The jsoncs3 manager does return ALREADY_EXISTS if it can read the share, based on resoucreid and grantee:

	// check if share already exists.
	key := &collaboration.ShareKey{
		// Owner:      md.Owner, owner no longer matters as it belongs to the space
		ResourceId: md.Id,
		Grantee:    g.Grantee,
	}

	_, err := m.getByKey(ctx, key)
	if err == nil {
		// share already exists
		err := errtypes.AlreadyExists(key.String())
		span.RecordError(err)
		span.SetStatus(codes.Error, err.Error())
		return nil, err
	}

But that test does not even share the same resource twice...

butonic · 2024-02-20T15:50:42Z

Ran into cs3org/reva#4530.

It should not solve the test failure ... but why does that granteeExists check return false ... when the Share request returns an ALREADY_EXISTS error?!?

ScharfViktor · 2024-02-20T16:39:24Z

Failed asserting that an array contains '104' only reproducible using api test. E2e tests are green.

error occurs only AFTER we perform step sharing to group

try to run this test:

 Scenario: 
    Given using spaces DAV path
    And group "grp1" has been created
    And user "Brian" has been added to group "grp1"
    And user "Alice" has uploaded a file inside space "Alice Hansen" with content "some content" to "textfile.txt"
    And user "Alice" has uploaded a file inside space "Alice Hansen" with content "some content2" to "textfile1.txt"
    And user "Alice" has uploaded a file inside space "Alice Hansen" with content "some content3" to "textfile2.txt"
    And user "Alice" creates a share inside of space "Alice Hansen" with settings:
      | path      | textfile.txt |
      | shareWith | grp1        |
      | shareType  | 1                        |
      | role      | editor       |
    Then the HTTP status code should be "200"
    And the OCS status code should be "200"

    And user "Alice" has shared file "textfile2.txt" with user "Brian"
    Then the HTTP status code should be "200"
    And the OCS status code should be "200"
   
   And user "Alice" creates a share inside of space "Alice Hansen" with settings:
      | path      | textfile1.txt |
      | shareWith | Brian        |
      | role      | editor       |
    Then the HTTP status code should be "200"
    And the OCS status code should be "200"

butonic · 2024-02-20T17:05:13Z

hm

{"level":"error","service":"sharing","pkg":"rgrpc","traceid":"3f3f6f6c205e1e716fb799090b2bf1b3","hostname":"965c0b73b289","userID":"eeaedb89-922c-411f-a0fe-3751acd023d4","spaceID":"878b1b24-8445-46d7-b1e3-001899415023:59284822-8b4e-464b-8605-48c416260344","error":"error: already exists: already exists","time":"2024-02-20T11:12:04Z","message":"persisting added received share failed"}

butonic · 2024-02-20T19:47:33Z

Added some more ocs logging. This created https://drone.owncloud.com/owncloud/ocis/32231/34/4

{
    "level": "error",
    "service": "sharing",
    "pkg": "rgrpc",
    "traceid": "67c152ba8fe5e60832bf9f364520b6dc",
    "hostname": "490f84f10870",
    "userID": "15469b59-2480-4797-94a0-0a66d1a9f36c",
    "spaceID": "18243f69-1507-4b8e-a74b-115d8843f9bf:476a6fa1-e1e3-492d-b796-d8a37cdecbdb",
    "error": "error: already exists: already exists",
    "time": "2024-02-20T19:40:45Z",
    "message": "persisting added received share failed"
}

{
    "level": "error",
    "service": "frontend",
    "pkg": "rhttp",
    "traceid": "5da84c776f26fa04d57725106058457a",
    "request-id": "coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:265-285",
    "error": "error creating share: error: already exists: already exists",
    "ocs_msg": "A share for the recipient already exists",
    "time": "2024-02-20T19:40:45Z",
    "message": "writing ocs error response"
}

{
    "level": "error",
    "service": "sharing",
    "pkg": "rgrpc",
    "traceid": "2ca37030f357392aba20e4386e22a15a",
    "hostname": "490f84f10870",
    "userID": "a14b68a7-5a8a-4afc-bd10-c5eef43097a1",
    "spaceID": "18243f69-1507-4b8e-a74b-115d8843f9bf:56f67e03-f733-479a-b59b-a902d36f5e68",
    "error": "error: already exists: already exists",
    "time": "2024-02-20T19:40:49Z",
    "message": "persisting added received share failed"
}

{
    "level": "error",
    "service": "frontend",
    "pkg": "rhttp",
    "traceid": "114b490c50d3ae9f378af62bdafdff61",
    "request-id": "coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:297-312",
    "error": "error creating share: error: already exists: already exists",
    "ocs_msg": "A share for the recipient already exists",
    "time": "2024-02-20T19:40:49Z",
    "message": "writing ocs error response"
}

{
    "level": "error",
    "service": "sharing",
    "pkg": "rgrpc",
    "traceid": "68b51c30ff43c877a8b907d1f5112888",
    "hostname": "490f84f10870",
    "userID": "0c97cf84-2172-4431-8a5b-8a9d953162f0",
    "spaceID": "18243f69-1507-4b8e-a74b-115d8843f9bf:4b3da9e3-8590-4a39-b18b-2af7b1b4c47f",
    "error": "error: already exists: already exists",
    "time": "2024-02-20T19:40:53Z",
    "message": "persisting added received share failed"
}

{
    "level": "error",
    "service": "frontend",
    "pkg": "rhttp",
    "traceid": "7c7af5d0bf3547ee242cee8f706b57b4",
    "request-id": "coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:324-340",
    "error": "error creating share: error: already exists: already exists",
    "ocs_msg": "A share for the recipient already exists",
    "time": "2024-02-20T19:40:53Z",
    "message": "writing ocs error response"
}

{
    "level": "error",
    "service": "sharing",
    "pkg": "rgrpc",
    "traceid": "8ff4d400caaf0045605023e477933b65",
    "hostname": "490f84f10870",
    "userID": "e692116b-6a57-44fc-9059-e1f8b1096b1d",
    "spaceID": "18243f69-1507-4b8e-a74b-115d8843f9bf:146d2ef2-aef6-4986-8d75-89c6f50aaf6a",
    "error": "error: already exists: already exists",
    "time": "2024-02-20T19:40:56Z",
    "message": "persisting added received share failed"
}

{
    "level": "error",
    "service": "frontend",
    "pkg": "rhttp",
    "traceid": "06c49ca3f22dafa2f15e3f35c20aa192",
    "request-id": "coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:350-366",
    "error": "error creating share: error: already exists: already exists",
    "ocs_msg": "A share for the recipient already exists",
    "time": "2024-02-20T19:40:56Z",
    "message": "writing ocs error response"
}

{
    "level": "error",
    "service": "sharing",
    "pkg": "rgrpc",
    "traceid": "7fa9a6c227bbcf6bada344410395991c",
    "hostname": "490f84f10870",
    "userID": "ff60542f-26d7-4288-9b8d-96c019f9b701",
    "spaceID": "18243f69-1507-4b8e-a74b-115d8843f9bf:c0bf52a8-ffb3-48e2-8ee3-f6ab9eb421fd",
    "error": "error: already exists: already exists",
    "time": "2024-02-20T19:40:59Z",
    "message": "persisting added received share failed"
}

{
    "level": "error",
    "service": "frontend",
    "pkg": "rhttp",
    "traceid": "2158b46ccc5528fa9b001bf6718dfcc5",
    "request-id": "coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:376-391",
    "error": "error creating share: error: already exists: already exists",
    "ocs_msg": "A share for the recipient already exists",
    "time": "2024-02-20T19:40:59Z",
    "message": "writing ocs error response"
}

and in https://drone.owncloud.com/owncloud/ocis/32231/35/4

{
    "level": "error",
    "service": "sharing",
    "pkg": "rgrpc",
    "traceid": "7db3c8ade71b0c1ea51c71c572c11413",
    "hostname": "c4a1b5c5e858",
    "userID": "db8541d4-366e-44ae-812e-26d7cb4c9def",
    "spaceID": "9812b81b-b85e-4549-8fe3-606dbfb53a4c:8c0b71b7-2e7b-4c2a-a8bb-76fdd22c0e7a",
    "error": "error: already exists: already exists",
    "time": "2024-02-20T19:38:29Z",
    "message": "persisting added received share failed"
}

{
    "level": "error",
    "service": "frontend",
    "pkg": "rhttp",
    "traceid": "4f089c03c0c4b030ad7b15777bef5bba",
    "request-id": "coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:474-486",
    "error": "error creating share: error: already exists: already exists",
    "ocs_msg": "A share for the recipient already exists",
    "time": "2024-02-20T19:38:29Z",
    "message": "writing ocs error response"
}

{
    "level": "error",
    "service": "frontend",
    "pkg": "rhttp",
    "traceid": "0c5ac2f7ed7df3073acbb811f0e2526a",
    "request-id": "coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:500-509",
    "error": "cannot set the requested share permissions",
    "ocs_msg": "Cannot set the requested share permissions",
    "time": "2024-02-20T19:38:33Z",
    "message": "writing ocs error response"
}

{
    "level": "error",
    "service": "frontend",
    "pkg": "rhttp",
    "traceid": "96da2e73273862b7803ff55e01536e33",
    "request-id": "coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:516-525",
    "error": "cannot set the requested share permissions",
    "ocs_msg": "Cannot set the requested share permissions",
    "time": "2024-02-20T19:38:37Z",
    "message": "writing ocs error response"
}

{
    "level": "error",
    "service": "frontend",
    "pkg": "rhttp",
    "traceid": "6f45ae8e91300017fd2d97c4e6d91687",
    "request-id": "coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:532-543",
    "error": "cannot set the requested share permissions",
    "ocs_msg": "Cannot set the requested share permissions",
    "time": "2024-02-20T19:38:42Z",
    "message": "writing ocs error response"
}

butonic · 2024-02-20T19:57:41Z

Hah, got it. This is caused by cs3org/reva#4528 which now actually checks the IfNoneMatch header.

And persist() in the jsoncs3 share manager also uses it:

	ur := metadata.UploadRequest{
		Path:        jsonPath,
		Content:     createdBytes,
		IfMatchEtag: rss.etag,
	}
	// when there is no etag in memory make sure the file has not been created on the server, see https://www.rfc-editor.org/rfc/rfc9110#field.if-match
	// > If the field value is "*", the condition is false if the origin server has a current representation for the target resource.
	if rss.etag == "" {
		ur.IfNoneMatch = []string{"*"}
	}

	_, err = c.storage.Upload(ctx, ur)

At least I think that causes this. @ScharfViktor looking at the logic the code tries to write the userJSONPath(userID) which might not exist if the user has just been created! HAH!

ScharfViktor · 2024-02-20T20:32:53Z

At least I think that causes this. @ScharfViktor looking at the logic the code tries to write the userJSONPath(userID) which might not exist if the user has just been created! HAH!

yes, I can confirm it using UI.

create new user
share file or folder to new user

Actual:

But then I can't understand why the e2e tests and all the api tests don't fail. After each test we delete user Alice and create new user Alice (different uuid). That should be enough to get an error.

butonic · 2024-02-20T21:46:03Z

It also has to do with the group shares. I'll take a look tomorrow.

Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>

sonarqubecloud · 2024-02-21T08:46:00Z

Quality Gate passed

Issues
0 New issues

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

See analysis details on SonarCloud

* bump dependencies Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de> * bump reva and add config options Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de> --------- Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>

butonic force-pushed the bump-reva-deps branch 2 times, most recently from e2094c8 to f4cec36 Compare February 9, 2024 13:55

butonic force-pushed the bump-reva-deps branch from f4cec36 to af13d83 Compare February 19, 2024 09:32

butonic marked this pull request as ready for review February 19, 2024 09:34

butonic mentioned this pull request Feb 19, 2024

CORS on /data does not work #8380

Closed

butonic self-assigned this Feb 19, 2024

butonic added p1-urgent Priority:p2-high Escalation, on top of current planning, release blocker and removed p1-urgent labels Feb 19, 2024

micbar reviewed Feb 19, 2024

View reviewed changes

vendor/go-micro.dev/v4/api/options.go Show resolved Hide resolved

micbar approved these changes Feb 19, 2024

View reviewed changes

butonic force-pushed the bump-reva-deps branch 2 times, most recently from 38cc8e8 to 515cc2a Compare February 19, 2024 15:01

butonic force-pushed the bump-reva-deps branch from 515cc2a to e4b12c6 Compare February 20, 2024 10:00

butonic force-pushed the bump-reva-deps branch from e4b12c6 to b408fa8 Compare February 20, 2024 10:09

butonic mentioned this pull request Feb 20, 2024

fix: InitiateFileUploadRequest_IfNotExist options has to be set with … cs3org/reva#4528

Merged

butonic force-pushed the bump-reva-deps branch from b408fa8 to 87c1fb4 Compare February 20, 2024 10:46

bump dependencies

dfff052

Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>

butonic force-pushed the bump-reva-deps branch from 87c1fb4 to 0da7437 Compare February 20, 2024 11:04

butonic mentioned this pull request Feb 21, 2024

jsoncs3 cache fixes cs3org/reva#4532

Merged

butonic force-pushed the bump-reva-deps branch from cecaced to 5433ca0 Compare February 21, 2024 07:53

bump reva and add config options

b451d38

Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>

butonic force-pushed the bump-reva-deps branch from 5433ca0 to b451d38 Compare February 21, 2024 08:34

butonic merged commit 5ed57cc into master Feb 21, 2024
3 checks passed

delete-merged-branch bot deleted the bump-reva-deps branch February 21, 2024 09:20

This was referenced Feb 21, 2024

OCS error message for attempting to access share via share id as an unauthorized user is not informative #1233

Closed

[OCIS] invalid status code on OCS requests for object that doesn't exist owncloud/product#250

Closed

ScharfViktor mentioned this pull request Feb 21, 2024

[test-only] share items with share permission if resharing is disabled #8461

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Bump reva deps #8412

Bump reva deps #8412

butonic commented Feb 8, 2024 •

edited

Loading

update-docs bot commented Feb 8, 2024

micbar left a comment

butonic commented Feb 19, 2024

butonic commented Feb 19, 2024

butonic commented Feb 19, 2024

ScharfViktor commented Feb 19, 2024

saw-jan commented Feb 20, 2024

butonic commented Feb 20, 2024 •

edited

Loading

butonic commented Feb 20, 2024

butonic commented Feb 20, 2024

butonic commented Feb 20, 2024

ScharfViktor commented Feb 20, 2024

saw-jan commented Feb 20, 2024

butonic commented Feb 20, 2024

butonic commented Feb 20, 2024 •

edited

Loading

butonic commented Feb 20, 2024 •

edited

Loading

butonic commented Feb 20, 2024 •

edited

Loading

butonic commented Feb 20, 2024

butonic commented Feb 20, 2024 •

edited

Loading

butonic commented Feb 20, 2024

ScharfViktor commented Feb 20, 2024

butonic commented Feb 20, 2024

butonic commented Feb 20, 2024 •

edited

Loading

butonic commented Feb 20, 2024

ScharfViktor commented Feb 20, 2024

butonic commented Feb 20, 2024

sonarqubecloud bot commented Feb 21, 2024

Bump reva deps #8412

Bump reva deps #8412

Conversation

butonic commented Feb 8, 2024 • edited Loading

update-docs bot commented Feb 8, 2024

micbar left a comment

Choose a reason for hiding this comment

butonic commented Feb 19, 2024

butonic commented Feb 19, 2024

butonic commented Feb 19, 2024

ScharfViktor commented Feb 19, 2024

saw-jan commented Feb 20, 2024

butonic commented Feb 20, 2024 • edited Loading

butonic commented Feb 20, 2024

butonic commented Feb 20, 2024

butonic commented Feb 20, 2024

ScharfViktor commented Feb 20, 2024

saw-jan commented Feb 20, 2024

butonic commented Feb 20, 2024

butonic commented Feb 20, 2024 • edited Loading

butonic commented Feb 20, 2024 • edited Loading

butonic commented Feb 20, 2024 • edited Loading

butonic commented Feb 20, 2024

butonic commented Feb 20, 2024 • edited Loading

butonic commented Feb 20, 2024

ScharfViktor commented Feb 20, 2024

butonic commented Feb 20, 2024

butonic commented Feb 20, 2024 • edited Loading

butonic commented Feb 20, 2024

ScharfViktor commented Feb 20, 2024

butonic commented Feb 20, 2024

sonarqubecloud bot commented Feb 21, 2024

Quality Gate passed

butonic commented Feb 8, 2024 •

edited

Loading

butonic commented Feb 20, 2024 •

edited

Loading

butonic commented Feb 20, 2024 •

edited

Loading

butonic commented Feb 20, 2024 •

edited

Loading

butonic commented Feb 20, 2024 •

edited

Loading

butonic commented Feb 20, 2024 •

edited

Loading

butonic commented Feb 20, 2024 •

edited

Loading