Sp-dev-docs: SiteID now is SiteId ??????????

[MagtheRag]

Category

• [ ] Question
• [ ] Typo
• [x] Bug
• [ ] Additional article idea

Expected or Desired Behavior

When search through the rest api as in '/_api/search' then I expect that the properties of each search row object is presented in the same way and not change casing suddenly so that the code that we have IN PRODUCTION breaks as we do not find the property we are looking for.

Observed Behavior

In Target release tenant the response has changed when selecting the SiteID to SiteId.

Steps to Reproduce

Do a search in a target release tenant
[tentant]/_api/search/query?querytext=%27*%27&selectproperties=%27SiteID%27

Submission Guidelines

Thanks for your contribution! Sharing is caring.

[msft-github-bot]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[andrewconnell]

I'm not clear... what are you seeing that's different? I ran the same query in two tenants, one SR & one TR and the results are the same...

[CPritch]

I can confirm repro following @MagtheRag repro steps. The response from a developer tenant is that 'SiteID' has now become 'SiteId'. A tenancy not on first-release responds with the key 'SiteID' for the request as described.

[andrewconnell]

I'm still not clear... sorry, maybe I'm a little dense on this one, but I don't see the difference or what the "error" is as when I run the same query for the same two properties, SiteID or SiteId on an SR & TR tenant, I'm getting the same response back for both.

I wasn't familiar with the property being SiteID previously, but when I query for SiteID or SiteId, I'm getting the same response... so the casing isn't changing an issue.

So... what exactly is the issue?

[CPritch]

Yes the casing is changing. I can get more details on the affected tenants if you need that. SiteID was being returned for our UK production tenants from when I last tested this.

[andrewconnell]

You're missing the point of my comment: what is the exact problem. The OP provides an API to get a property. When you change the query to either of the values, you get the same result.

So, my impression is that the OP is calling out you get different results based on the casing used. My point: that's not what I'm seeing & thus, can't repro any issue. Thus my "not clear" comment & label on the issue.

If that's not the correct problem, it needs to be restated / explicitly stated.

[MagtheRag]

The problem is when you have an app that reads from the properties and assume that the property should be SiteID then it does not exist and you will not find that property on the object that is returned. It is not that we are trying to query for the site id. We want to fetch it.

[andrewconnell]

This helps @MagtheRag, thanks. I thought the issue was related to the query you were running.

[CPritch]

You're missing the point of my comment: what is the exact problem. The OP provides an API to get a property. When you change the query to either of the values, you get the same result.

So, my impression is that the OP is calling out you get different results based on the casing used. My point: that's not what I'm seeing & thus, can't repro any issue. Thus my "not clear" comment & label on the issue.

If that's not the correct problem, it needs to be restated / explicitly stated.

I am saying your interpretation is incorrect @andrewconnell . The issue is that in production tenants the key is SiteID. In dev and first-release tenants the key is SiteId. The key has recently changed in first-release tenants. You can confirm this difference by performing the repro steps between a dev tenant and a production tenant.

The answer to prevent this causing issue in production code is clearly not to use first-release for production environments. I still believe that this is an issue as the key should not have changed without being warned of breaking changes.

[andrewconnell]

@CPritch said

I am saying your interpretation is incorrect

Yup... I get that now :) But, this isn't true & what was triggering me to keep asking questions:

You can confirm this difference by performing the repro steps between a dev tenant and a production tenant.

There's no difference between "dev" & "production" tenants... they are all tenants. What does make this different is targetted release / standard release. What I was saying is that I wasn't seen an issue with the difference in the queries I was running among a handful of my tenants, some TR & some SR.

Regardless, the problem was the issue wasn't clear from the OP, while I thought it was the query results. We're on track now

The answer to prevent this causing issue in production code is clearly not to use first-release for production environments.

Correct... this has been the guidance from day 1. TR is what you'll see in SR in a few weeks... guidance has been to use TR environments as a test/canary for upcoming changes.

[wobba]

@MagtheRag I'll try to repro and track this one down.

[karolikl]

@MagtheRag & @CPritch:

Thank you for notifying us of this bug! This was not an intentional change, our intention is to keep the casing as it has been all along, but this bug appeared in a flight that was enabled on First Release tenants last week. Standard Release tenants are unaffected.

Our dev team has checked in a fix for this today and it will roll-out to First Release by end of the week. If this bug is causing major issues for your First Release tenants, please send me an overview of which tenants those are and we will disable the flight for those. Email: [email protected]

[andrewconnell]

@karolikl / @wobba can you follow up here when the fix has rolled out so we can close this accordingly? Feel free to mention me with the hashtag "please-close"

[MagtheRag]

I have fixed a work-around in our search abstraction layer if any of these mistakes would happen again. But good that this issue will have your attention and that you ensure that it is not rolled out to the standard release tenants where most of our customer is at.

[karolikl]

This fix is now fully rolled out, @andrewconnell. Feel free to close this issue.

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues