looks like a yes https://github.com/juji-io/datalevin/blob/733bbf309221b8a87204e15d16b3be23807b3a8f/src/datalevin/pull_api.cljc#L311

Do we need to cache here? This code is the same as Datascript

:man-shrugging: I’ll investigate more next week. It’s very bizarre it looks like a combination of state & cache: the pull works until it stops working and once it stops working we can make it work by just modifying the selector (like swapping the order of two attributes). Thus the workaround (changing the cache key) hints to caching but the behavior (pull stopping to work) hints that there’s something stateful directly or indirectly associated with the cache key.

Right, probably should not cache these

Removed caching here, as our DB is not immutable.

I have no clear repro yet (I will certainly revisit it in a couple of weeks). Something crossed my mind today: what if it’s a bug with cycles detection in pull request? (The thing which returns just {:db/id xxx} when the entity is already seen.) this would explain the failure mode. Anyway I hope the bug is gone now that you removed the cache.