Could it be that something in your setup (e.g. editor plugins) is attaching metadata?

Metadata affects equality semantics in XT

I’m posting through http api, so I suppose I can’t add any meta data into the map :thinking_face:

Could there be some issue with keyword namespacing here also?

Huh I suppose I don't have to iterate through the whole transaction log thanks to after-tx-id so something like (.next (open-tx-log node (dec tx-id) true)) appears to get me a single transaction by its ID

Hey @U0EPG0ED7 , generally the recommendation here is to reify your transaction metadata into additional entities ahead of time, so that the necessary info is available via regular querying. Calling open-tx-log may be okay though, but might be slow/expensive depending on your specific tx-log choice

Postgres logging / monitoring may give some clues. It sounds like it is struggling to take out the necessary locks

I truncated the tx_events table in the Postgres tx log and restarted the K8s pod to drop the Rocks index (no persistent volumes), and XT came back to life (I could safely drop all this data). There were 1,507,606 rows in tx_events. Could writes have been blocked because maybe node was in process of ingesting those events…maybe timing out somehow? Are locks still prime suspect? How do they work? I had previously restarted the node (w/o dropping tx_events) and that didn’t make any difference. I imagine if a node is busy ingesting tx log (no snapshotting), that reads would also be blocked?

Regular queries should generally work regardless of ingestion, but open-tx-log or entity calls could fail if ingestion-related connectivity is not working for whatever reason

I don't grasp how the locking works in huge detail but the jdbc module isn't massive to read and get a feel for, so I can recommend it

Locking varies a lot in practice based on the actual database backend being used, with different dialects

transaction function

Wrap your tx fn code in a try/catch and in the catch block, return the exception details in a document with a fixed xt/id. I've got an example somewhere, one sec

Thanks, I get what you mean. I'm doing that already sans the try catch. Will add that now!

https://github.com/juxt/site/blob/actions/src/juxt/pass/alpha/actions.clj#L426

Another common reason for a tx false is of your tx fn returns a document without a xt/id attribute

Looks like the transaction-fn wasn't being set up in my fixtures. With the addition of the transaction function everything's in order. I added the try-catch block to the function while I was at it so progress was made!

Thank you!