Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor sharing #1685

Merged
merged 6 commits into from
May 17, 2021
Merged

Refactor sharing #1685

merged 6 commits into from
May 17, 2021

Conversation

C0rby
Copy link
Contributor

@C0rby C0rby commented May 5, 2021

  • extract share creation into its own method
  • extract state conversion into its own method
  • extract resource info retrieval
  • some minor clean up
    Also the responses to accepting or rejecting a share return the updated share now.

@update-docs
Copy link

update-docs bot commented May 5, 2021

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.

@C0rby C0rby force-pushed the refactor-sharing branch 5 times, most recently from a9cf4b6 to eeede49 Compare May 6, 2021 12:39
@C0rby
Copy link
Contributor Author

C0rby commented May 6, 2021

I don't quite get why

apiSharePublicLink1/deletePublicLinkShare.feature:37
apiSharePublicLink1/deletePublicLinkShare.feature:38

fail...
Locally they run just fine...
@individual-it or @phil-davis do you have an idea?

Also @ishank011 or @labkode, I don't have access to the cs3org in snyk so I can't see what test is failing there. Could you tell me what I need to fix?

@C0rby
Copy link
Contributor Author

C0rby commented May 6, 2021

I don't quite get why

apiSharePublicLink1/deletePublicLinkShare.feature:37
apiSharePublicLink1/deletePublicLinkShare.feature:38

fail...

I think I found the issue.

@C0rby
Copy link
Contributor Author

C0rby commented May 6, 2021

Listing a public link after renaming it fails for some reason....
Need to investigate further...

@labkode labkode requested a review from ishank011 May 7, 2021 05:30
@individual-it
Copy link
Contributor

sadly the logs of reva are cut off in drone

@individual-it
Copy link
Contributor

I rebased on master here #1690 let's see
Next I will try to bump the oc-core commit id

@phil-davis
Copy link
Contributor

sadly the logs of reva are cut off in drone

In owncloud drone CI we put a flush of the file-system and a 30-second wait at the end of acceptance test runs. That improved the situation - pipeline step output seemed to get from the drone agent to drone server more often! I am not sure what happens currently in cs3org/reva CI.

@C0rby
Copy link
Contributor Author

C0rby commented May 7, 2021

@individual-it, my refactoring is causing the issue. I just haven't found the cause yet...

@C0rby
Copy link
Contributor Author

C0rby commented May 7, 2021

Arrgh I found it...

When we are doing a stat request on a share like here

statResponse, err := c.Stat(ctx, statRequest)

we eventually end up here

ip, err := redis.String(c.Do("GET", id.OpaqueId))

In that line we get the file path using the OpaqueId as the key. When we rename a file, that path will be wrong because it doesn't get updated on a file rename. Because of that the stat request fails with a not found error.

Back in the listPublicShares method we check the result of the stat

statResponse, err := c.Stat(ctx, statRequest)
if err != nil || res.Status.Code != rpc.Code_CODE_OK {

But if you look closely you see that it doesn't check the status code of the stat response but of the listPublicShare response.

My refactoring changed that to checking the stat response and that's why it doesn't return a share after the shared file gets renamed...

@C0rby
Copy link
Contributor Author

C0rby commented May 7, 2021

This is the underlying issue. #1693 Will work on it on monday

@C0rby
Copy link
Contributor Author

C0rby commented May 10, 2021

Waiting for this fix to be merged: #1696

@C0rby C0rby force-pushed the refactor-sharing branch 3 times, most recently from e7b817e to aa9780f Compare May 10, 2021 16:03
@C0rby C0rby marked this pull request as ready for review May 10, 2021 16:03
@C0rby C0rby requested a review from labkode as a code owner May 10, 2021 16:03
@labkode
Copy link
Member

labkode commented May 17, 2021

@ishank011 can you review this one?

butonic
butonic previously approved these changes May 17, 2021
}

share := getShareRes.Share
share := res.Share
if share == nil {
panic("gateway: error updating a received share: the share is nil")
}
createRefStatus, err := s.createReference(ctx, share.Share.ResourceId)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add checks for createRefStatus and err?

additionalInfoTemplate *template.Template
userIdentifierCache *ttlcache.Cache
resourceInfoCache gcache.Cache
resourceInfoCacheTTL time.Duration
useResourceInfoCache bool
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we use it in the user-configurable struct? If a user sets useResourceInfoCache to true but doesn't set resourceInfoCacheTTL assuming a default value, we won't use the cache. I'd suggest removing this and checking the value of resourceInfoCacheTTL in all places

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, no it's not user configurable. But I'd still vote for removing the extra variable. Doesn't really add any value

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does add a bit of readability but I have no hard opinion on this, I can remove it again.

@ishank011 ishank011 merged commit 72e1c88 into cs3org:master May 17, 2021
@C0rby C0rby deleted the refactor-sharing branch May 21, 2021 12:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants