xt/tx-committed?

ah that's already helpful. I guess there's no way to get an indication back of why it failed?

try/catch, logging and then re-throwing any errors is probably the easiest thing to do during development. The only non-side-effecting, application-visible way to observe the failure in production is to catch the error and write it into the db as data (then potentially re-throwing it...depending on the level of the error)

@U07FP7QJ0 I write a summary of the error to the database, it works fine.

looks like that's the way to go, I'll play around with it. Probably useful in general to have some "operation log" entities. Thanks for the input!

https://github.com/juxt-site/site/blob/master/src/juxt/site/actions.clj#L376 is my code that does this, if that helps. It's a rather unnecessarily long function though, apologies.

adding an audit document for every tx is a good idea too @U07FP7QJ0

We've permitted more Rocks compaction jobs on multi-core machines (2 or ncpus-1, whichever is higher)

Indexing is pipelined across multiple threads too, which you want cores available for.

ncpu-1 means it wasn't as bad at scaling as I thought