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

[BUG] The Basic Discovery Service Should Return A Cursor That Is Useful For The Subsequent Request #422

Open
geso02 opened this issue Sep 3, 2024 · 2 comments
Labels
bug Something isn't working good first issue Good for newcomers

Comments

@geso02
Copy link
Contributor

geso02 commented Sep 3, 2024

The Basic Discovery Service should return a cursor that is useful for the subsequent request. If I do a GET-Request on the following URL:
/lookup/shells?limit=2

I get this response for my test:

{
  "paging_metadata" : {
    "cursor" : "https://acplt.org/Test_AssetAdministrationShell2"
  },
  "result" : [ "https://acplt.org/Test_AssetAdministrationShell1", "https://acplt.org/Test_AssetAdministrationShell2" ]
}

Also for other services, the id of the last item of the result list is returned, but it is always base64-url-encoded.

I can't use this cursor for the next request:

http://..../lookup/shells?limit=2&cursor=https://acplt.org/Test_AssetAdministrationShell2

To Reproduce

  1. Start the Basic Discovery Service
  2. Add multiple resources using this endpoint: POST /lookup/shells/{aasIdentifier}
  3. Request less resources than deployed: /lookup/shells?limit=2
  4. Have a look at the response body

Expected behavior

I would like to have a cursor that I can reuse for the next request. The shell id should be base64-url-encoded.

BaSyx (please complete the following information):

  • BaSyx Version [ v2.0]
  • BaSyx SDK [ Java]
  • AAS Version [DotAAS V3]

System (please complete the following information):

  • OS: [Docker on Windows]
  • CPU architecture: [ x86]
@geso02 geso02 added the bug Something isn't working label Sep 3, 2024
@github-project-automation github-project-automation bot moved this to To triage in Support Requests Sep 3, 2024
@geso02
Copy link
Contributor Author

geso02 commented Sep 3, 2024

I just tried to do the GET request for my example and it works:

curl http://localhost:8091/lookup/shells?cursor=https://acplt.org/Test_AssetAdministrationShell2
=>{"paging_metadata":{},"result":["https://acplt.org/Test_AssetAdministrationShell3"]}

Seems as curl and postman are quiet fault-tolerant. But at least when I have an id like this 'this&is=a&test' or spaces in the id, we will have a problem.

@aaronzi
Copy link
Member

aaronzi commented Sep 9, 2024

Hi Gerhard,
Thanks for reporting this bug. We will look into it.
And as always, if you have the time, please feel free to provide the fix yourself.

I will move this bug ticket to ready to be picked up. If you decide to work on it, please let me know.

@aaronzi aaronzi added the good first issue Good for newcomers label Oct 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working good first issue Good for newcomers
Projects
Status: Ready
Development

No branches or pull requests

2 participants