3

Environment is Sites 9.6, DXA 2.2 (.NET), using si4t for search functionality. Intermittently, developers are seeing that for a page which has not been recently published and which could be successfully browsed to previously, fails with 404 error on webpage. When viewing Content service logs, see error such as the below.

"Caused by: com.fasterxml.jackson.core.JsonParseException: Unexpected character ('<' (code 60)): expected a valid value (JSON String, Number, Array, Object or token 'null', 'true' or 'false')" " at [Source: (String)""/en/contact-us/index.htmlLOREM IPSUM8476776477277240LOREM IPSUMLOREM IPSUM:INDEX-DATA-END --><!-- ""[truncated 3410 chars]; line: 1, column: 2]" ... "2023-04-21 10:15:15.191 ERROR [content-service,SERVERINFO] 13 --- [o2-8081-exec-42] .c.g.e.CustomDataFetcherExceptionHandler : Exception while fetching data (/page/rawContent) : Error occurred while transforming page content" com.sdl.delivery.content.model.core.datafetcher.transformer.ModelTransformerException: Error occurred while transforming page content

On republishing the page, page can again be viewed successfully. I've retrieved the page content via graphql, and have compared the output of the failing and working content. When page fails, there are extraneous si4t tags in the json rawContent, ie

<!-- INDEX-DATA-START:<indexdata><url> ... :INDEX-DATA-END -->

After republishing page, these tags are removed.

Related links are
Page is not loaded when using SI4T TBB
https://github.com/SI4T/SI4T/issues/4
https://github.com/RWS/dxa-modules/issues/26
TridionSites 9.6 and DXA 2.2 upgraded: PCA client returned an unexpected response when retrieving page model data for page

As an aside, I believe the last link is possibly from a developer working in a different team for the same issue. Questions are:

  • Is it correct for si4t tags to be stored in the broker database? From first link which admittedly is old, I believe it is not. I'm not clear then why the page was working successfully for the past few weeks, and suddenly fails to display with a 404. Also all other pages in the same publication fail until being republished.
  • Why is the same publish action resulting in different output? Regardless of what the correct behavior is, I would expect the si4t tags to consistently be added or not added to the json when publishing.
  • Should the Content service be able to display webpage if there are si4t tags embedded in content?
Improve this question

1 Answer 1

Reset to default
5

these tags should not be there in graphql. The workflow is the following:

  1. templating code adds these si4t xml data within INDEX-DATA-START and END tags
  2. Deployer picks these tags, remove them from the output and pushes them in elastic or solr, whichever you use
  3. page without these tags is deployed in broker

Since you are seing these tags within broker, it means that somehow step 2 failed. The exact code that does this is within si4t-se.jar. For more details check TridionPublishableItemProcessor class: enter image description here

Improve this answer
3
  • somehow step 2 failed probably the page(s) were published while the deployer was misconfigured
    – Nuno Linhares ♦
    Apr 23 at 2:40
  • yes, thats normaly the case. failing in storage extension does not revert page publish by default.
    – Marko Milic ♦
    Apr 23 at 20:28
  • Many thanks both. I'm still not clear why the pages continued to display successfully via Content service when the index tags were resident (until they didn't), but at least I'm clear what the expected behavior for si4t is.
    – Terry Kim
    Apr 24 at 14:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.