Known issues in Content Delivery

The following list describes issues that are known to exist in Content Delivery.

Requests for non-published items still require a database roundtrip, possibly impacting performance

In certain scenarios, a query for an item that was never published (for example, as part of trying to resolve a hyperlink) results in a request to the database. The item being requested is what is called a "null value." Previously, such a query for a null value would be resolved by the cache. But now, such a query always results in a (fruitless) database roundtrip, which has the potential of impacting performance.

If multiple base URLs were specified when configuring a Content Delivery environment in Topology Manager, Content Delivery queries return a random base URL

In Topology Manager, the Add-TtmWebsite script for configuring a website allows you to specify a list of one or more base URLs for the website. Specifying multiple base URLs can be useful if visitors access your website using multiple base URLs, say, by the site's IP address or by a hostname.

However, with the website configured this way, a Content Delivery query return a URL that randomly uses one of the base URLs specified. For example, imagine that you have set the BaseUrls property of the Add-TtmWebsite command to "http://myhost:84/", "http://122.3.4.5/", and that your website runs the following query to get an image called example.jpg:
{
  tcm_binary: link(namespaceId: 1, publicationId: 5, itemId: 258, type: BINARY) {
    url
  }
}
The response to this query would now randomly be one of the following:
http://myhost:84/example.jpg
or
http://122.3.4.5/example.jpg

To prevent this from happening, set BaseUrls to a single value when you run the Add-TtmWebsite script.

Specifying multiple targets for UGC in Topology Manager does not work

In Topology Manager, you can add UGC to a Publication mapping by including the ExtensionProperties switch in your Set-TtmMapping command, in which you specify a value for the UGCTargetName property.

All UGC Capabilities need to reference one single target. It is not possible to configure multiple UGC targets, especially if you use multiple UGC databases.

Content API filtering on custom metadata does not work if the metadata keys or values contain non-Latin characters
Here is an example of a GraphQL Content API query that does not return proper results, but instead returns null:
{
  publications(namespaceId: 2, filter: {value: "conditionset.generated.value={\"Пример1\":[\"Вибірка 3\"],\"مثال\":[\"متغير2\"]}", valueType: STRING, queryType: CUSTOM_META}) {
    edges {
      cursor
      node {
        publicationId
        itemType
      }
    }
  }
}
Content API filtering on a Float format returns null
Here is an example of a GraphQL Content API query that does not return proper results, but instead returns null:
{
  publications(namespaceId: 2, filter: {value: "ishlogicalref.object.id=1312760.0", valueType: FLOAT, queryType: CUSTOM_META}) {
    edges {
      cursor
      node {
        publicationId
        itemType
      }
    }
  }
}
Large sitemaps may lead to connection timeout errors

On a Java/JSP site, out of the box, the value of the ConnectionTimeout attribute in the client cofiguration file, cd_client_conf.xml, may prove too short for retrieving a large sitemap. To work around this issue, increase ConnectionTimeout to a value that can handle your sitemap.

Custom number fields turned to float

Integer and number values are stored in a float column type in the Content Delivery broker database. Therefore the values are rounded when they are retrieved. This may introduce inaccuracies for certain decimal numbers. This affects only custom fields.

Content Service throws null pointer exception in response to a query with a non-existent URL

When using the dynamic metadata API to get back Page metadata for a URL that does not exist, the Content Service throws a null pointer exception, rather than a friendly and informative error message.

Publish transactions fail in a high-volume publishing scenario

If you are executing a high-volume publish, you might find that some publish actions fail.

This is due to incidental conflicts that occur when the Content Data Store database is updated. Content Delivery has a fallback mechanism to deal with this problem: it retries the deployment of the content for up to 10 times. But if the number of conflicts is too high, this may not be enough.

If this happens, you have the following options:
  • You can set up your Content Deployer as a separate endpoint and worker, and set up multiple Content Deployer workers so that you can handle high-volume publishing.
  • If you want to limit yourself to a single Content Deployer worker, contact SDL Customer Support to obtain the latest hotfixes for SDL Tridion Docs 14, and go through the Troubleshooting section to learn how to fine-tune your Publisher and Content Deployer.
  • Finally, you can republish the content that failed.
A Taxonomy Keyword with multiple parents can no longer retrieve its multiple parents

In the event that a Keyword in your Taxonomy has multiple parents, a call to primaryKeyword.getParentKeywords() used to be able to retrieve said parents. But this API call no longer works properly.

Some older versions of CIL require a hotfix to talk to the CIS included with SDL Tridion Docs 14

If you are using Content Interaction Libraries from before SDL Tridion Sites 9 to talk to the SDL Tridion Docs 14 Content Interaction Services (microservices), contact SDL Customer Support to obtain a hotfix.