that's correct, though also note that :biff.xtdb/retry is true by default--i.e. you can set that flag to false if you want to skip the call to await-tx

Is there a reason you wouldn't want await without the retry logic?

The main thing is that await takes time, and there may be cases where you don't want to wait for the result + you're not worried about contention. e.g. in the eelchat tutorial, when you create a new chat message, it sets retry to false so that the http request will have a quicker response time: https://github.com/jacobobryant/eelchat/blob/b335f8208606373f3f19f9e25f97a19d47d19766/src/com/eelchat/app.clj#L155

if you meant "why doesn't biff/submit-tx have an option to call await-tx without doing the retry logic"--I don't see any advantage of calling await-tx without the retry logic. Again the main cost of the retry logic is that you have to wait for the transaction to get indexed, so if you're already doing that, there's not much cost to double checking that the transaction actually succeeded. If you did want to do that though, you can do (xt/await-tx (biff/submit-tx (assoc ctx :biff.xtdb/retry false) ...))

I assumed based on the docs that submit-tx awaited everything so that if I had a read after a submit, it would be up to date. Not that it was only for retry logic. This bit isn't near the retry section. Might be worth clarifying > Biff will call xt/await-tx on the result, so you can read your writes.

yeah, agree that could be clearer. I'm doing a batch of xtdb-related things soon; I'll add this to the list. similarly I wonder if Biff should somehow help people avoid the pitfall of calling biff/submit-tx and then querying the old database snapshot and expecting it to have the new results... I think in xtdb2 they made it so by default you just pass in the node and it'll query the most recent available snapshot automatically. Anyway.