For example in the tests of the Search 5 migration helper, we have something like this:
@Spatial applies a bridge to the Coordinates object returned by getLocation(), marking its getLatitude() and getLongitude() methods as indexing dependencies. But getLocation() is also marked as derived from other properties...
And we get that kind of failure:
The cause seems to be that we take derivedFrom into account only when a dependency is declared to the property values directly, not when a dependency is declared to nested properties.
I believe that, as long as all the dependencies involved are not entities, we should simply ignore all dependencies to nested properties:
When an entity is involved at any point, then it's possible that ignoring the dependency might result in problems, so we'd better throw an exception.
But as long as all dependencies are non-entities, we can assume they are not managed and were simply built as the result of a calculation. And we supposedly already know all the dependencies of that calculation thanks to derivedFrom.