Flaky api-test. share manager migration causes space creation to return 500

[v-scharf]

https://ci.opencloud.rocks/repos/3/pipeline/1965/152

  Scenario Outline: lock a file in the project space using file-id                                                                       # /woodpecker/src/github.com/opencloud-eu/opencloud/tests/acceptance/features/apiLocks/lockFiles.feature:116
    Given the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API                                      # GraphContext::theAdministratorHasGivenTheRoleUsingTheGraphApi()
    And using spaces DAV path                                                                                                            # FeatureContext::usingOldOrNewOrSpacesDavPath()
    And user "Alice" has created a space "Project" with the default quota using the Graph API                                            # SpacesContext::theUserHasCreatedASpaceByDefaultUsingTheGraphApi()
    And user "Alice" has uploaded a file inside space "Project" with content "some content" to "textfile.txt"                            # SpacesContext::userHasUploadedFile()
    And we save it into "FILEID"                                                                                                         # FeatureContext::saveItInto()
    And user "Alice" has sent the following space share invitation:                                                                      # SharingNgContext::userHasSentTheFollowingShareShareInvitation()
      | space           | Project      |
      | sharee          | Brian        |
      | shareType       | user         |
      | permissionsRole | <space-role> |
    When user "Brian" locks file "textfile.txt" using file-id "<<FILEID>>" using the WebDAV API setting the following properties         # WebDavLockingContext::userLocksFileUsingFileIdUsingWebDavAPISettingFollowingProperties()
      | lockscope | exclusive   |
      | timeout   | Second-3600 |
    Then the HTTP status code should be "200"                                                                                            # FeatureContext::thenTheHTTPStatusCodeShouldBe()
    When user "Brian" sends PROPFIND request from the space "Project" to the resource "textfile.txt" with depth "0" using the WebDAV API # SpacesContext::userSendsPropfindRequestFromTheSpaceToTheResourceWithDepthUsingTheWebdavApi()
    Then the HTTP status code should be "207"                                                                                            # FeatureContext::thenTheHTTPStatusCodeShouldBe()
    And as user "Brian" the PROPFIND response should contain a resource "textfile.txt" with these key and value pairs:                   # SpacesContext::asUsertheXMLResponseShouldContainMountpointWithTheseKeyAndValuePair()
      | key                                                  | value        |
      | d:lockdiscovery/d:activelock/d:lockscope/d:exclusive |              |
      | d:lockdiscovery/d:activelock/d:depth                 | Infinity     |
      | d:lockdiscovery/d:activelock/d:timeout               | Second-3600  |
      | d:lockdiscovery/d:activelock/oc:ownername            | Brian Murphy |

    Examples:
      | space-role   |
      | Manager      |
        Failed step: And user "Alice" has created a space "Project" with the default quota using the Graph API
        Expected response status code should be 201 (Created)
        Failed asserting that 500 matches expected 201.
      | Space Editor |
        Failed step: And user "Alice" has created a space "Project" with the default quota using the Graph API
        Expected response status code should be 201 (Created)
        Failed asserting that 500 matches expected 201.

The share manager was migrating!
https://ci.opencloud.rocks/repos/3/pipeline/1965/153

### And using spaces DAV path
	### And user "Alice" has created a space "Project" with the default quota using the Graph API
		_______________________________________________________________________

		==> REQUEST [2026-08-21T6:26:25]
		GET /graph/v1.0/me
		X-Request-ID: apiLocks/lockFiles.feature:112-91

		_______________________________________________________________________

		==> REQUEST [2026-08-21T6:26:25]
		POST /graph/v1.0/drives
		X-Request-ID: apiLocks/lockFiles.feature:112-91
		==> REQ BODY
		{"name":"Project"}

		<== RESPONSE [2026-08-21T6:26:25]
		500 Internal Server Error
		X-Xss-Protection: 1; mode=block
		<== RES BODY
		{"error":{"code":"generalException","innererror":{"date":"2026-08-21T06:26:25Z","request-id":"apiLocks/lockFiles.feature:112-91"},"message":"error creating share: error: aborted: share manager is currently migrating, please retry"}}

@aduffeck ... are we aware of this?

[fredrikblau]

I'd like to work on this issue. I'll investigate the share-manager migration race and add a focused fix/test for the flaky API scenario.

[fredrikblau]

I opened PR #3392. It retries only the transient 500 response share manager is currently migrating, please retry, which matches the failure reported here. I verified the current backend guard and acceptance request flow; a live acceptance run was not possible because PHP and Composer are unavailable in my environment.