Cycle Detected in Content Delivery API After Converting a IDataListSource to IPublishedContent

[markadrake]

Edit:
I created a demo repo. Comment below.

I've found myself in another situation, hoping someone can add the missing context for me.

I created a custom Data List Source. This data source grabs only the appropriate content nodes, which the author can choose from as a property editor.

Before implementing the IDataSourceValueConverter →
Umbraco Models Builder returned a string, ultimately the GUID of the chosen content item.

After implementing the IDataSourceValueConverter →
Umbraco Models Builder returns IPublishedContent
but simultaneously causes the Content Delivery API to cycle into oblivion.

JsonException: 
A possible object cycle was detected. This can be due to a cycle or if the object depth is larger than the maximum allowed depth of 32. Consider using ReferenceHandler.Preserve on JsonSerializerOptions to support cycles. 
Path: 
$.Items.Properties.Content.Content.ContentType.PropertyTypes.ContentType.PropertyTypes...

• I attempted adding an IDeliveryApiPropertyValueConverter to my project, but it naturally conflicted with the existing converter for Data Lists.
• I also changed some settings on the Content Delivery API, but to no avail. This resulted in new errors at each step.
• I'd like to return IPublishedContent for the Models Builder without breaking the Content Delivery API. It may be a misconfiguration on my part.

I'm stumped again. 🫣

Thank you for any insights that you can provide!

[markadrake]

Here is an instance of using Contentment that causes the cycles. This is unrelated to my issue above, but perhaps there's some insight into what is happening here.

• I have an OOTB Block Editor.
• Block Editor is configured for multiple entries of a single type, Service Record to Supplier Category.
• The first screenshot below shows the Service Record property, a Data List.
• All standard configurations here. I don't think anything is custom.

[markadrake]

I read the docs for deeply nested JSON and have tried various settings:

builder.Services.AddControllers().AddJsonOptions(
    Constants.JsonOptionsNames.DeliveryApi,
    options =>
    {
        // set the maximum allowed depth of
        options.JsonSerializerOptions.ReferenceHandler = ReferenceHandler.IgnoreCycles;
        options.JsonSerializerOptions.MaxDepth = 64;
    });

Unfortunately, this leads to other exceptions:

  "title": "System.NotSupportedException",
  "status": 500,
  "detail": "Serialization and deserialization of 'System.Type' instances is not supported. Path: $.Properties.Pages.Parent.Parent.Parent.Parent.Children.Children.ContentType.PropertyTypes.ModelClrType.",

And sometimes:

  "title": "System.Text.Json.JsonException",
  "status": 500,
  "detail": "The object or value could not be serialized. Path: $.Items.Properties.Items.Content.Properties.PropertyTypes.DataType.Configuration.",

And this one is incredibly annoying, as it suggests setting Preserve even after I have it set.

  "title": "System.Text.Json.JsonException",
  "status": 500,
  "detail": "A possible object cycle was detected. This can either be due to a cycle or if the object depth is larger than the maximum allowed depth of 4. Consider using ReferenceHandler.Preserve on JsonSerializerOptions to support cycles. Path: $.Items.ContentType.",

[markadrake]

I'm sorry @leekelleher,
I know that I'm completely insane. 🤣

I created a minimal demo using a fresh install of Umbraco 13. There's so much going on in my production application that it would be good to rule out any of our first-party code.

[markadrake]

While troubleshooting this and other issues,
we discovered compatibility issues with Contentment and the Content Delivery API.

You might already be aware.

There's been a wonderful update by the ByteCrumb team that describes the issue much better than I ever could.

[leekelleher]

@markadrake A quick reply, as I haven't looked into this issue yet. I haven't used the Delivery API with Contentment before, so was hoping that someone would shout if there were any issues... and now I'm aware of the serialization troubles.
Thanks for gathering all the info and the demo repo to reproduce the issue. 🙏 I'll take a look into this in the coming days.

[markadrake]

I'm very thankful, and if I can contribute in any way towards the goal, please let me know.

I'm reviewing the PR and the issue's description to understand it better. I need to improve with the force (C#). 🔦

All the best,

[leekelleher]

Good news, I have a pull request ready that will resolve this. PR #428. Thanks to @vsilvar for his workaround patch too! 🙏

I still have some testing to do, but my aim to get this ready for a v5.1.0 release soon.

[leekelleher]

Closing off this discussion, as has been resolved by PR #428.