I tried upgrading from Umbraco 15.4.4 to the latest version, 16.3.1. The website starts up successfully the first time after the upgrade, but on subsequent attempts, I get the following error:
InvalidOperationException: All calls to HybridCache with the same key should use the same data type; the same key is being used for 'Umbraco.Cms.Infrastructure.HybridCache.ContentCacheNode' and 'Umbraco.Cms.Infrastructure.HybridCache.ContentCacheNode' data
Initially, I thought the issue was caused by some custom services, but I tested the Umbraco upgrade using the same database on a clean Umbraco project (the default Umbraco template) with no additional packages.
The result is the same — it upgrades successfully the first time I start it, but on subsequent startups, the website gets stuck with the same error mentioned above.
psot
October 21, 2025, 4:20pm
3
I’ve come across that previously, I remember having to do something with rebuilding.
Have you tried deleting the cache folder and then just building?
warren
October 21, 2025, 4:31pm
4
Looks like this issue
opened 09:25AM - 17 Oct 25 UTC
closed 11:15AM - 21 Oct 25 UTC
type/bug
release/17.0.0
release/16.3.2
### Which Umbraco version are you using?
17.0.0
### Bug summary
When booting … the site after a build I get the below Hybrid Cache error:
`InvalidOperationException: All calls to HybridCache with the same key should use the same data type; the same key is being used for 'Umbraco.Cms.Infrastructure.HybridCache.ContentCacheNode' and 'Umbraco.Cms.Infrastructure.HybridCache.ContentCacheNode' data`
### Specifics
_No response_
### Steps to reproduce
<img width="1844" height="293" alt="Image" src="https://github.com/user-attachments/assets/c1a32f22-04b7-4b9c-ae2c-2415df955f82" />
A refresh of the site loads the site fine.
### Expected result / actual result
_No response_
---
_This item has been added to our backlog AB#61023_
And due for 17.0 and 16.3.2
main ← v16/bugfix/hybrid-cache-error
opened 09:30PM - 19 Oct 25 UTC
### Prerequisites
- [X] I have added steps to test this contribution in the d… escription below
Addresses: https://github.com/umbraco/Umbraco-CMS/issues/20537
### Description
This PR makes two updates to resolve the linked issue;
- Ensure we use a nullable type when checking for existence to align with retrieving from or creating in the cache. As were using a nullable type for one and not the other, this could explain why the hybrid cache sees misaligned types but reports them as the same.
- Ensure we use the same overload for checking existence and retrieving from or creating in the cache. Possibly there's an issue here with the incorrect state object being applied meaning the types are considered different.
For background, this "exists" check was added in https://github.com/umbraco/Umbraco-CMS/pull/19890 which was introduced to improve start up performance (allowing us to retrieve cached documents in batches from the database rather than one at a time).
I was able to reproduce the problem manually - it seemed to be consistent at least when using the Visual Studio template and IIS Express:
- Create a new Umbraco project using 16.3.1.
- Create a document type with a property, a template and a root content item.
- Start Umbraco via Ctrl + F5 using IIS Express.
- The reported error message could be seen.
The amends described above resolved the problem with the hybrid cache exception but revealed something else - that we would get an immediate page not found, and then after a refresh, the expected templated page would show. The crux of the problem here seemed to be that we are doing seeding on an application started notification, which doesn't seem correct. We should seed the initial content before we accept requests, and as such I've moved this to an application starting notification. That looks to resolve this problem.
There are some integration tests added in an attempt to replicate the problem. These didn't succeed in doing so, but are probably worth keeping anyway as additional testing around the hybrid cache.
Similarly there's some tightening up around the implementation of the "exists" check (the locking around "check and remove" and the cancellation token handling). None of this turned out to be the smoking gun, but I think they are valid improvements to consider keeping.
### Testing
First try to replicate the problem consistently on `main` and then when you can, switch in the code from this PR and verify that the application starts without error and the expected initial page is shown.
1 Like
