Sitecore Forms long labels truncated

The cause of this is fairly straightforward, but given how painful it is to debug I thought I'd post this for anyone else who comes across it.

If you are using Sitecore Forms, and ever have the need to use a very long label in a list item (eg. a checkbox list) you will notice it gets truncated. You may even note that the length is suspiciously similar to the max length of an item name...

After a lot of digging you'll note that these list item label/value strings are altered and set in Sitecore.ExperienceForms.Mvc.DataSource.DataSourceSettingsManager, specifically in the UpdateStaticItems method where there is a call to ItemUtil.ProposeValidItemName() for both label text and value. This is certainly required for one (if it's being set as the name or display name) however not for both.

Thanks to dependency injection the fix is nice and easy to patch in:

<?xml version="1.0"?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/"  xmlns:role="http://www.sitecore.net/xmlconfig/role/">
  <sitecore>
    <services>
      <register serviceType="Sitecore.ExperienceForms.FieldSettings.IFieldSettingsManager`1[[Sitecore.ExperienceForms.Mvc.Models.ListFieldItemCollection, Sitecore.ExperienceForms.Mvc]], Sitecore.ExperienceForms" 
        patch:instead="register[@serviceType='Sitecore.ExperienceForms.FieldSettings.IFieldSettingsManager`1[[Sitecore.ExperienceForms.Mvc.Models.ListFieldItemCollection, Sitecore.ExperienceForms.Mvc]], Sitecore.ExperienceForms']"
        implementationType="MyProject.Feature.Forms.DataSource.DataSourceSettingsManager, MyProject.Feature.Forms" lifetime="Transient" />
    </services>
  </sitecore>
</configuration>

When Disabling xDB Isn't Enough

If you read the documentation on using CMS-only mode to run Sitecore without xDB you'd be forgiven for thinking that a config patch such as this is the simple end of the story:

<configuration>
    <sitecore>
        <settings>
            <setting name="Xdb.Enabled" value="false" />
            <setting name="Xdb.Tracking.Enabled" value="false" />
        </settings>
    </sitecore>
</configuration>

Unfortunately as someone on Slack recently discovered, this doesn't help if you're trying to run Sitecore (XP container images, but in CMS-only mode without the xConnect instances) in containers. 

The issue is fairly obvious when you notice CM is not starting and take a look at an example of the logs

920 08:52:34 ERROR Health check Sitecore.XConnect.Client.WebApi.CollectionWebApiClient completed after 0.0038ms with status Unhealthy and 'Error during CollectionWebApiClient initialization: An error occurred while sending the request.'

1920 08:52:35 ERROR Health check Sitecore.XConnect.Client.WebApi.ConfigurationWebApiClient completed after 0.0054ms with status Unhealthy and 'Error during ConfigurationWebApiClient initialization: An error occurred while sending the request.'

1920 08:52:36 ERROR Health check Sitecore.XConnect.Client.WebApi.SearchWebApiClient completed after 0.0068ms with status Unhealthy and 'Error during SearchWebApiClient initialization: An error occurred while sending the request.'

Yes, there are in fact health checks on CM and CD which check the status of xConnect, and completely ignore the config settings I mentioned above.

Not to worry, there are a couple of options at this point:

1. Use a config patch to remove the health checks (the easier option)
2. Update and override the health checks so that they respect the Xdb.Enabled setting

Config patch

Here's an easy patch you can apply which should remove these from your Sitecore configuration and complete the disabling of xDB:

Updating the code

The "proper" way, I feel, would be to update the code to respect the Xdb.Enabled setting. This is what the setting is indicating, and what the documentation explains that it is for.

To take XConnectCollectionHealthCheckServicesConfigurator as an example:

public class XConnectCollectionHealthCheckServicesConfigurator : Sitecore.XConnect.Client.Configuration.HealthCheckServicesConfigurators.XConnectCollectionHealthCheckServicesConfigurator
{
  protected override IHealthCheck CreateCommonWebApiHealthCheck(IServiceProvider provider)
  {
    if (Sitecore.Configuration.Settings.GetBoolSetting("Xdb.Enabled", true))
      return base.CreateCommonWebApiHealthCheck(provider);
    else
      return new SuccessHealthCheck();
  }
}

public class SuccessHealthCheck : IHealthCheck
{
  public Task<HealthCheckResult> CheckHealthAsync(HealthCheckContext context, CancellationToken cancellationToken = default)
  {
    return Task.FromResult(HealthCheckResult.Healthy());
  }
}

We add our settings check, and - because there does not seem to be any easy out-of-the-box way to return a successful health check - we also need to create a class for that. Repeat for all 3 health checks, and you're good to go.

Enjoy running your Sitecore topology nice and lean!