Summary

When upgrading to Optimizely.ContentGraph.Cms 4.2.0 in an Optimizely CMS 12 solution that also uses Optimizely.Graph.Commerce 1.3.0, the application fails at runtime due to a breaking change in the Content Graph context API.

Optimizely.Graph.Commerce 1.3.0 depends on the concrete class ContentGraphContextAccessor, while Optimizely.ContentGraph.Cms 4.2.0 has moved to an interface-based design for this context. Even with manual DI workarounds, additional method signature changes cause the Graph Commerce integration to break.

Affected Components and Versions

• CMS: Optimizely CMS 12 (DXP / PaaS scenario)

• Content Graph: Optimizely.ContentGraph.Cms 4.2.0

• Graph Commerce: Optimizely.Graph.Commerce 1.3.0

• Commerce: Optimizely Commerce 14 (backend; context for the Graph Commerce package)

Symptoms

After updating Optimizely.ContentGraph.Cms to 4.2.0 and keeping Optimizely.Graph.Commerce at 1.3.0, the site fails to start with a DI error similar to:

System.InvalidOperationException: Unable to resolve service for type 'Optimizely.ContentGraph.Cms.NetCore.Internal.ContentGraphContextAccessor' while attempting to activate 'Optimizely.Graph.Commerce.Converters.CommerceGraphPropertyConverterProvider'.

This happens because the Graph Commerce package still expects direct injection of the concrete ContentGraphContextAccessor class, which is no longer registered the same way (and has changed) in ContentGraph 4.2.0.

Technical Root Cause

In Optimizely.Graph.Commerce 1.3.0 we have the following internal implementation:
 
internal class CommerceGraphPropertyConverterProvider : IPropertyConverterProvider { private readonly ContentGraphContextAccessor _contentGraphContextAccessor; // ... }

Key points:

1. Concrete class dependency

   • The provider directly depends on ContentGraphContextAccessor (a concrete class from Optimizely.ContentGraph.Cms.NetCore.Internal).

   • This type is an internal implementation detail of Content Graph and not part of a stable public interface contract.

2. Content Graph 4.2.0 architecture change

   • In newer versions, Content Graph has moved to an interface-based abstraction for its context access (e.g. IContentGraphContextAccessor and related interfaces).

   • DI registrations are now done primarily for the interfaces, not for the concrete class.

3. Method / signature changes

   • Beyond DI registration, the structure and signatures of some methods on the context classes have changed (e.g. different parameters / overloads).

   • Even if you try to “re-register” or recreate a ContentGraphContextAccessor in DI as a workaround, CommerceGraphPropertyConverterProvider is compiled against the old API shape and expects the old method signatures.

   • This leads to runtime issues once those methods are actually used.

Result:
The Optimizely.Graph.Commerce 1.3.0 package is binary-incompatible with Optimizely.ContentGraph.Cms 4.2.0.

Why Simple DI Workarounds Do Not Fix It

You might try to fix the DI error by manually registering the accessor, for example:
 
services.AddTransient<ContentGraphContextAccessor>(); // or mapping to an interface services.AddTransient<IContentGraphContextAccessor, ContentGraphContextAccessor>();

However, this does not fully resolve the problem because:

• The implementation of ContentGraphContextAccessor in 4.2.0 differs from the version that Optimizely.Graph.Commerce 1.3.0 was built for.

• Methods used internally by CommerceGraphPropertyConverterProvider on the accessor may:

  • No longer exist,

  • Have changed parameter lists or types,

  • Or behave differently.

• This results in runtime failures when the provider tries to call those methods (even if DI now resolves the type).

So the issue is not just missing DI registration, but a fundamental API mismatch between the two packages.

Impact

• Graph Commerce integration cannot be used with the current combination:

  • Optimizely.ContentGraph.Cms 4.2.0

  • Optimizely.Graph.Commerce 1.3.0

• The site may:

  • Fail to start due to DI errors

• This blocks:

  • Indexing and exposing Commerce content via Optimizely Graph / Content Graph,

  • Any frontend or integration relying on Graph Commerce projections.

Recommendations / Next Steps

1. Align package versions

   • Avoid using Optimizely.ContentGraph.Cms 4.2.0 together with Optimizely.Graph.Commerce 1.3.0.

   • Options:

     • Downgrade Content Graph to a version that is known to work with Graph.Commerce 1.3.0, or

     • Wait for / request a new version of Optimizely.Graph.Commerce that is built against the newer Content Graph 4.x interface-based design.

2. Document as a known limitation

   • Mark this combination as not supported in our internal compatibility matrix:

     • ✅ CMS 12 + Commerce 14 + ContentGraph (≤ x.y.z) + Graph.Commerce 1.3.0

     • ❌ CMS 12 + Commerce 14 + ContentGraph 4.2.0 + Graph.Commerce 1.3.0

3. Avoid custom hacks around internal types

   • Do not rely on manually registering ContentGraphContextAccessor or patching its implementation:

     • It is an internal class, not part of a stable API.

     • Even if DI works, method signature changes make this fragile and error-prone.

4. Raise with Optimizely

   • Open a support ticket / feature request:

     • Describe that Optimizely.Graph.Commerce 1.3.0 still depends on the concrete ContentGraphContextAccessor while Optimizely.ContentGraph.Cms 4.2.0 moved to interfaces and changed method signatures.

     • Request an updated Optimizely.Graph.Commerce version that:

       • Depends on the interfaces instead of the internal class,

       • Is compiled against the current Content Graph API.

Conclusion

This is a version compatibility issue between Optimizely.ContentGraph.Cms and Optimizely.Graph.Commerce, caused by:

• Direct use of the internal ContentGraphContextAccessor class in CommerceGraphPropertyConverterProvider, and

• The refactoring of Content Graph 4.2.0 to interface-based context access with changed method signatures.

Until Optimizely releases a Graph Commerce version that targets the newer Content Graph API, we should not combine Optimizely.ContentGraph.Cms 4.2.0 with Optimizely.Graph.Commerce 1.3.0 in the same solution.