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

[QA] OCM: failing invite produces no readable error messge #10208

Open
Tracked by #9735
jnweiger opened this issue Oct 1, 2024 · 3 comments
Open
Tracked by #9735

[QA] OCM: failing invite produces no readable error messge #10208

jnweiger opened this issue Oct 1, 2024 · 3 comments
Labels

Comments

@jnweiger
Copy link
Contributor

jnweiger commented Oct 1, 2024

Describe the bug

A clear and concise description of what the bug is.

Steps to reproduce

Setup three machines with e.g.

env OCIS_DNSNAME=ocis1-DATE OCIS_VERSION=v6.4.0 ./deploy_ocis_bare_metal.sh
env OCIS_DNSNAME=ocis2-DATE OCIS_VERSION=v6.4.0 ./deploy_ocis_bare_metal.sh
env OCIS_DNSNAME=ocis3-DATE OCIS_VERSION=v6.4.0 ./deploy_ocis_bare_metal.sh
  • mutually register the machines in their ocmproviders.json; service ocis restart
  • user alice at ocis2 generates an invite token.
  • user bob at ocis3 tries to accept the token, but wrongly chooses ocis1 in the 'Select institution of inviter' dropdown.
  • an error appears. OK

image

  • The error has no hint what is wrong. the user should be able to understand, what he clicked wrong, without analyzing log files. BAD
  • journalctl -u ocis | grep e1039eae-a842-4154-8008-466f05788dcc does not ave a good hint either. BAD
Oct 01 15:32:28 jw-ocis-v6-4-0-oj9 ocis[49923]: {"level":"debug","service":"ocm","pkg":"rhttp","traceid":"22167da66ff7aa1d6582baa1fff08375","request-id":"e1039eae-a842-4154-8008-466f05788dcc","path":"/accept-invite","time":"2024-10-01T15:32:28Z","line":"github.com/cs3org/reva/[email protected]/internal/http/services/sciencemesh/sciencemesh.go:139","message":"sciencemesh routing"}
Oct 01 15:32:28 jw-ocis-v6-4-0-oj9 ocis[49923]: {"level":"info","service":"proxy","proto":"HTTP/1.1","request-id":"e1039eae-a842-4154-8008-466f05788dcc","traceid":"f75aa12d8850867ba4f3b0117c4525c8","remote-addr":"87.148.40.122","method":"POST","status":401,"path":"/sciencemesh/accept-invite","duration":42.635172,"bytes":74,"time":"2024-10-01T15:32:28Z","line":"github.com/owncloud/ocis/v2/services/proxy/pkg/middleware/accesslog.go:34","message":"access-log"}

Expected behavior

  • The error message could e.g. say "The invite token was not found on instance institution ocis1"

FYI: @hodyroff @nicholas-wilson-au

@jnweiger
Copy link
Contributor Author

Idea: The "institution" could be encoded in the invite token, to eliminate this problem.

@jnweiger
Copy link
Contributor Author

jnweiger commented Dec 17, 2024

The above idea is implemented in 7.0.0-rc.5 / Web 11.0.6

Downside: There was a second use-case for the institution dropdown. Users could review there, which other hosts they can federate with. Now that the dropdown is gone, we don't even know if the ocmprovider setup is in place.

Next idea: A useful error message would be to enumerate the list of registered ocmprovides, in case an invite token from a different host is processed.

@2403905 2403905 added the Priority:p2-high Escalation, on top of current planning, release blocker label Feb 24, 2025
@2403905 2403905 moved this from Qualification to Prio 2 in Infinite Scale Team Board Feb 24, 2025
@2403905
Copy link
Contributor

2403905 commented Feb 24, 2025

Not only OCM Invitation falling produce no readable error, but also creating or updating the ocm share when the remote federated instance is not reachable.

@2403905 2403905 moved this from Prio 2 to Prio 3 or less in Infinite Scale Team Board Mar 6, 2025
@2403905 2403905 added Priority:p3-medium Normal priority and removed Priority:p2-high Escalation, on top of current planning, release blocker labels Mar 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Prio 3 or less
Development

No branches or pull requests

2 participants