Skip to main content

Sitecore XM with CD bug - _hasLayout property not working in GraphQL

Hi Team,

Recently I was working on a search solution, it was simple filtration functionality and we wanted to have simple GraphQL queries so we can get items as we need.

The setup up is Sitecore XM scaled with CM and CDs (No experience edge)

So, I just wrote simple GQL and were trying to test its results, Query worked just fine, and we were satisfied but we also wanted to have a filter for only items which had some presentation details, because we only wanted to return search results which are created from certain templates and having a presentation set on them, So the search list page will link those pages to those items.

So, I just put a standard check of _hasLayout property, using which we could target only those items which have presentation details on them, like following.


By just introducing the _hasLayout property It stopped working, though this particular project was not on XM Cloud, we tried testing it on XM Cloud environment as it is a generic search GQL, and we found out that over there _hasLayout property is working just fine and returning results.

That means, we found that there is something wrong with Sitecore XM with CDs, I tried following.

1) In the QUERY VARIABLES section, I tried passing values like "true", "false", "" but nothing worked

2) Just to check I passed " " (Empty space) and it return everything without applying filter of _hasLayout

So, behavior was wired, and we easily could figure out that there is some issue with the _hasLayout property being set by the Graph QL code somewhere in the DLL

Solution

I opened up the Sitecore Support Ticket and provided the information, after initial troubleshooting, Sitecore registered this as a bug in their tracking system with bug reference number 551736

They provided us the package of two DLLs 

1) Sitecore.Service.GraphQL.dll

2) Sitecore.Services.GraphQL.EdgeSchema.dll

After putting this hot fix, Things are working, and it returned us the results just fine as we wanted.


Just for my learnings, I will be dissembling those DLLs just to see what changed and what was missing in the standard Sitecore 10.3 XM DLLs which ships OOTB, if I find something will share it for you all too.



Labels:

Comments

Post a Comment

Popular posts from this blog

High CPU to completely normal CPU - SXA issue, SXA pages not loading in mobile device

  Hi Team, Today i am going to share one of the nightmarish issue with you all, We are having Sitecore 9.1.1 hosted in azure PaaS environment Our site was working just fine and no noise, but we have been working on a feature release where 7-8 months of development needed to be released to production, Big GO LIVE event right?  Also to make the development smoother we also introduced BLUE/GREEN deployment slots in the same release, so we can easily SWAP slots and go live Everything went well, we went live, we even did load and performance testing on our staging and pre-prod and we were confident enough of results Very next day we started getting "SITE DOWN" alerts, and also product owners and clients mentioned that site is very slow for them in US time and in our morning when we were accessing it, it was working lighting fast so we were clue less at start, but we started digging  1) First thing caught our eyes were HIGH CPU spikes, in US time, also without any traffic CPU u...
3 comments
Read more

Set up leprechaun code generation with Sitecore XM Cloud Starterkit

Hi Sitecorians, It has been amazing learning year so far and with the change in technology and shift of the focus on frontend frameworks and composable products, it has been market demand to keep learning and exploring new things. Reasons behind this blog Today's topic is something that was in my draft from April-May, and I always thought that there is already a good documentation out there for  Leprechaun  and a blog post is not needed, Until I realized that there was so many of us facing same kind of issues and same kind of problems and spending same amount of time, That is where I thought, if I could write something which can reduce that repetitive troubleshooting time, That would really help the community. 1)  In a project environment, if we get into some configuration issues, we resolve them, we make sure we are not blocked and continue, but if you think same issue, same step and same scenario will come to other people, so if we can draft it online, it will help othe...
Post a Comment
Read more

An error occurred while receiving the HTTP response to This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details.

You have noticed many times that everything was working fine and suddenly the below error starts coming and you find no way to work it out An error occurred while receiving the HTTP response to This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details. The reason for this is the receiving size of WCF service is smaller then the data which is coming from service It was working before because it was small,So you will have to try to increase the receiving setting in your end point,Possible settings can be following maxStringContentLength="2147483647" maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" maxArrayLength="2147483647" That would definately help you!!!
1 comment
Read more