Searching OneDrive through SDK returns wrong parent_id about livesdk HOT 10 CLOSED

This is a small bug in how the search data population works, and we aren't taking any changes in that space right now.

from livesdk.

Hi, Thanks for your response. This might be "small bug" for you but big for me and my app. I am unable to understand how can a issue with API that returns wrong unique id for an object can be a treated as small bug and closed. Though I understand that the problem might be at the api endpoint and not this live sdk. Can you please open up this issue or post an workaround other than sending another query with the primary object's id to get it's parent id?

from livesdk.

Gotcha. I have figured out what is wrong in our internal systems, and I've got a fix that will be out when our next major release gets to market. The problem is that we are exposing an internal data value that represents your root OneDrive folder, but our permission model with the LiveSDK does not let you query that value directly.

As to a workaround. There is a way to do this, but this is a terrible terrible hack that should be marked as such in your code and it should be expected that in time this will break. With that disclaimer, you can perform a little dissection on the resource ids to know if you are using the broken placeholder.

Consider the following ID:

file.8ae9dbc6c4a4c.8AE9DBC6C4A4C!39598

You could look at this internal reference number and determine if it is one of the numbers that is generated a bad response, around 105 or lower. These internal values are based on the internal data structures that are created for user accounts with the OneDrive service. For some older accounts this number could be very high for other accounts this number could be lower.

I would recommend that to work around this problem by adding the following to two options your program

1. If you detect a value of 110 or less on the resource id of an items parent, request the just that item information a second time so you get a valid parent's information.
2. Before you perform a search, query the root of the users OneDrive account and use that as a reference list to see if the search item's parent is the OneDrive root which you would use in place of the bugged 'id'.

from livesdk.

Thank you so much for looking into this issue. I would assume I get a notification via github when this fix is released. As for the workaround, I am currently already querying the parent id with each search result. But that is not appearing an acceptable UX due to additional lags being imposed when the search results are high in number.

Regarding your second point, can you please advise if the issue exists only for the immediate children of the root folder? If that is the case, I can cache the root children and that would solve my purpose. I won't implement this caching if the issue is widespread (deep down the root folder). Please let me know.

from livesdk.

This will happen on items that are at the root of a users OneDrive or a the root of a Group folder, if your app doesn't interact with group folders then you can just keep your root cache fresh and you should be able to avoid this issue.

We'll keep this issue around, and it will be closed when the service patch is live.

from livesdk.

@scpc0609 This change should be live now, could you give it a try and confirm that this is fixed? Actually this was a mistake, this change is not live yet, but its coming shortly!

from livesdk.

Thanks for the update

from livesdk.

Everything should be out now, please let me know if this issue is resolved.

from livesdk.

Hi, Thanks for the update. It appears this issues is fixed and can be closed now.

But intermittently I have seen that search takes a long time with empty pages being returned. This is not something that I have seen in the last few days.Not sure something around this has been fixed as well.

from livesdk.

Glad to hear that scenario is fixed. If you could capture a fiddler trace or something similar of those bad requests I can take a quick look, just open a new issue.

from livesdk.