Strange response for /getDetails Query

[pstoehr]

The response for this

{ "loggingLevel": 0, "queryID": "1174118456", "documentBadge": [ { "id": "24792b49-6db6-3af1-957d-3bcaf1003ff1", "uri": "http:\/\/www.mendeley.com\/research\/saint-peter-1", "provider": "Mendeley" } ], "origin": { "clientType": "Swift-Test-Client", "clientVersion": "0.21", "module": "OS X Prototype", "userID": "PDPS-WS2015" } }

/getDetails query

is this more or less empty json object: {"documentBadge":[],"queryID":"1174118456"}

Why is the original information about id, uri, and provider removed? This happened never before and we thought that /getDetails function call adds something to the documentBadge-Information provided by the /recommend function call.

Endpoint for the /recommend and /getDetails-call: https://eexcess-dev.joanneum.at/eexcess-privacy-proxy-issuer-1.0-SNAPSHOT/issuer/.

[chseifert]

Thomas, were there changes in the PP? (otherwise pls reassign to FR)

[ThomasCerq]

Nothing has changed recently on the PP, so I guess it comes from the FR. I think some changes have been made last week... I hand over to Hermann.

[hziak]

fixed it in a way that even on partner failure documentbadges should be returned

[n-witt]

I'm currently facing a same problem and did some investigations. I found that there are three types of items:

1. Items that I could never receive a result for
2. Items that I could occasionally receive a result for (2-3 out of 10 tries)
3. Items that I could almost always receive a result for.

Interestingly enough, I couldn't find a correlation regarding the data providers. Initially I assumed that there are some providers that respond faster than others and therefore their item are mostly type 3 items. But there are items of type 1 and 3 from the same provider in the same query.

What I also found is, that the problem can not be mitigated by reducing the number of item per query. Even queries with only one item show the same characteristics.

Type 1 example:

{
  "id":"24738970-9e37-3dc0-bb43-20d5c799b19b",
  "uri":"http://www.mendeley.com/research/diabetes-managed-care-lovelace-health-systems-episode-care-program",
  "provider":"Mendeley"
}

Type 2 example:

{
  "id":"/2022323/301B1706F223C8B81BDE555E89A8AFD42CE858B2",
  "uri":"http://europeana.eu/resolve/record/2022323/301B1706F223C8B81BDE555E89A8AFD42CE858B2",
   "provider":"Europeana"
}

Type 3 example:

{
  "id":"10004608579",
  "uri":"http://www.econbiz.de/Record/10004608579",
  "provider":"ZBW"
}

[pstoehr]

Is the version with the bugfix already online?

[hziak]

not yet, will be deployed later on today

[chseifert]

Reopen because

• we don't know how this has been fixed (e.g., what if partner recommenders do not respond, will there be an error code or an empty badge)
• this has not been tested since no deployment is available for the once reporting this issue

[schloett]

The issue 22 in the recommender repo seems to be related, just mentioning it here to have a crossreference.

[pstoehr]

Works for us now!