# Lookup refs used within a transaction are resolved against not the last state of DB **URL:** \ **Category:** Troubleshooting\ **Created:** [August 20, 2022, 5:48pm UTC](https://forum.datomic.com/t/lookup-refs-used-within-a-transaction-are-resolved-against-not-the-last-state-of-db/2114 "2022-08-20T17:48:05Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![nikolayandr](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.datomic.com/nikolayandr/32/375_2.png) [@nikolayandr](https://forum.datomic.com/u/nikolayandr)\ **Post date:** [August 20, 2022, 5:48pm UTC](https://forum.datomic.com/t/lookup-refs-used-within-a-transaction-are-resolved-against-not-the-last-state-of-db/2114/1 "2022-08-20T17:48:06Z")
Hi, the next case was met by executing simultaneous transactions where one of transaction used lookup ref to resolve entity to be updated: 1. Create entity e1 with unique attribute value `[:User/name "User-1"]` 2. Retract entity e1 3. Update e1 using lookup ref `[:User/name "User-1"]` Step 3 is expected to be failed with the error: `Unable to resolve entity: [:User/name \"User_1\"]` but we got the cases when the step 3 was executed successfully In our case step 2 and step 3 was executed by two different peers and according to transaction history with time in difference 8 seconds between them. To reproduce in `repl` within single peer the step 2 should be executed asynchronously ```auto (require '[datomic.api :as d]) (def connInternal (d/connect "datomic:dev://localhost:4334/dbName?password=datomic")) (def user-schema [ { :db/ident :User/name :db/valueType :db.type/string :db/cardinality :db.cardinality/one :db/unique :db.unique/value } { :db/ident :User/number :db/valueType :db.type/string :db/cardinality :db.cardinality/one } ]) (d/transact connInternal user-schema) (def user-1-name "User_1") (def user-data [ { :User/name user-1-name } ]) (d/transact connInternal user-data) (d/transact-async connInternal [[:db/retractEntity [:User/name user-1-name]]]) (def user-1-number "User_Number_1") (def user-updated-data [ { :db/id [:User/name user-1-name] :User/number user-1-number } ]) (d/transact connInternal user-updated-data) ``` ![image](https://us1.discourse-cdn.com/flex016/uploads/cognitect/original/1X/c54fed0b34007c72686912d2f24d5b698d67cf86.png) We see that the transaction `13194139534653` happened and after execution this transaction the entity looked as: ![image](https://us1.discourse-cdn.com/flex016/uploads/cognitect/original/1X/9f02931976a006b64742074041604b150460e7e8.png) where `:User/name` is absent what is expected due to transaction `13194139534652` P.S. Simply interesting: why the number 13194139534651 was not used to identify the second transaction? P.S.S. Looks like as lookup ref either was resolved by peer or by transactor but within the state of db which was actual when the transaction came to the transactor(when the second transaction were still in progress). But if to read [Identity and Uniqueness | Datomic](https://docs.datomic.com/on-prem/schema/identity.html#lookup-refs) and [Transactions | Datomic](https://docs.datomic.com/on-prem/transactions/transactions.html) then the issue is on transactor side P.S.S.S Lookup refs are used by us as the way to guarantee that the entity still exists ---
**Author:** ![nikolayandr](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.datomic.com/nikolayandr/32/375_2.png) [@nikolayandr](https://forum.datomic.com/u/nikolayandr)\ **Post date:** [August 22, 2022, 8:31am UTC](https://forum.datomic.com/t/lookup-refs-used-within-a-transaction-are-resolved-against-not-the-last-state-of-db/2114/2 "2022-08-22T08:31:05Z")
Datomic On-Prem 1.0.6202 ---
**Author:** ![nikolayandr](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.datomic.com/nikolayandr/32/375_2.png) [@nikolayandr](https://forum.datomic.com/u/nikolayandr)\ **Post date:** [August 22, 2022, 8:38am UTC](https://forum.datomic.com/t/lookup-refs-used-within-a-transaction-are-resolved-against-not-the-last-state-of-db/2114/3 "2022-08-22T08:38:31Z")
Another interesting behavior: if execute the script the second time then the third step returns the excepted error ---
**Author:** ![jaret](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.datomic.com/jaret/32/45_2.png) [@jaret](https://forum.datomic.com/u/jaret)\ **Post date:** [August 29, 2022, 12:33pm UTC](https://forum.datomic.com/t/lookup-refs-used-within-a-transaction-are-resolved-against-not-the-last-state-of-db/2114/4 "2022-08-29T12:33:32Z")
@nikolayandr Thank you for the report. We have reproduced this behavior and are looking at a fix in the next release of Datomic on-prem. I will update this thread when we have the release and fix in hand. ---
**Author:** ![nikolayandr](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.datomic.com/nikolayandr/32/375_2.png) [@nikolayandr](https://forum.datomic.com/u/nikolayandr)\ **Post date:** [August 14, 2023, 8:34am UTC](https://forum.datomic.com/t/lookup-refs-used-within-a-transaction-are-resolved-against-not-the-last-state-of-db/2114/5 "2023-08-14T08:34:50Z")
Hi, could you please tell me whether this issue has been resolved? ---
**Author:** ![jaret](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.datomic.com/jaret/32/45_2.png) [@jaret](https://forum.datomic.com/u/jaret)\ **Post date:** [August 29, 2023, 11:34am UTC](https://forum.datomic.com/t/lookup-refs-used-within-a-transaction-are-resolved-against-not-the-last-state-of-db/2114/6 "2023-08-29T11:34:32Z")
@nikolayandr yes, this was resolved in 1.0.6527: [Change Log | Datomic](https://docs.datomic.com/pro/changes.html#1.0.6527) > - Fix: Peer no longer resolves lookup refs before sending tx data to transactor. Sorry for not updating here as soon as the release last year.