What version of Datomic Cloud are you using? What topology (production or solo) and are you using query groups? What is the front end impact of these errors? Are you seeing any front end impact?
Thanks! I think we need to look closely at your logs and metrics. Would it be possible for you to log a case to our support portal and I can share the instructions for providing us ReadOnly CloudWatch log and metric access? You can log a case by shooting an e-mail to support@cognitect.com.
It doesn’t seem to take much to overwhelm the indexer which is surprising.
With log access, I am hoping to examine this more closely by putting some numbers on exactly what it takes to overwhelm, how long it takes for indexing to complete, etc.
After we’ve fully investigated, I can circle back and update this thread with our findings.
I am going to close this request now. We are seeing much better behavior after making our transaction size smaller and fixing a bug with having isComponent set to true but the id on the entity being unique causing a cascade on retractEntity.
We have a system that deals in different types of assets (USD, EUR, etc) and there is an entity for each type of Asset. Each Asset has a uuid that is defined with :db/unique :identity and we use ref to the Asset for each Entry we store.
All was well until we added :db/isComponent true to the Entry ref to the Asset. Once this was done, a retractEntity on an Entry results in the ref’d Asset being retracted from all the Entry entities that refer to it. This cascade resulted in a huge number of datoms being retracted in a single datomic transact.