yep, that’s the reason. you have a “temp” id (which is typically a string) in the txn data but there is no corresponding entity with that same id in the same txn.

typically this means you have an entity with a reference to another entity which is being created in the txn. if the referenced (to be created) entity doesn’t have a matching string :db/id you will get this error

so your statement that the matching id must be in “another tx” is incorrect. any string value in a :reference field must match another entity with that string in :db/id in the same tx

thanks! Sorry for the late reply.

In my experience, this happens only if the segments involved need to be regenerated for some other reason

No history only seems to mean “the next time I index this attribute, I won't write old values to the history indexes”. It doesn't actively seek to cull old values or consider that a reason to reindex by itself

Oh you’re talking about turning it off after it's been on. No, I don't think it will regenerate history but I'm less sure

I think indexing only considers previous index + novel datoms since last index; it won't go through entire tx log

thank you

No. If you need history to be mutable, you should track that history yourself rather than relying on Datomic history.

There’s one exception only, you can explicitly set the :db/txInstant of a transaction in the “past” (wall-clock time) as long as there is no existing transaction with a higher value. This is designed for initial imports. https://docs.datomic.com/cloud/transactions/transaction-processing.html#explicit-txinstant

@U09R86PA4 perfect thank you.