hyrax: Ldp::Conflict occurring on all new works once it starts

@no-reply In case it helps … I just encountered this error on my workstation in our Hyrax-based app. I attempted to create an object through the UI but, due to an error in some new actor code I had just written, an exception was thrown. I corrected the code error and tried again. This time, I got the Ldp::Conflict error. I opened a rails console and typed the command you listed above; namely, [::Noid::Rails::Service.new.minter.mint, ::Noid::Rails::Service.new.minter.mint]. I got ["5999n337h", "rf55z7713"]. (I actually then ran the command again and got two different id’s, but I think that’s probably irrelevant to the issue at hand.) I then restarted my rails server and again attempted to add a new work through the UI. That time, it succeeded. So, in response to the question you posed above, at least in this case, when the Ldp::Conflict occurred, I was able to successfully mint new ids outside of the actor stack and that seems to have caused the problem to go away.

Fun fact - this also appears to clear up an issue with minters taking forever to get their lock - since in postgresql the lock stays open until the transaction is over. we’ve seen a big improvement with multiple workers with this fix.

@orangewolf that all seems congruent with my understanding.

I’ve looked at adding a separate transaction for the minter; the thing is that it already has one: https://github.com/samvera/noid-rails/blob/master/lib/noid/rails/minter/db.rb#L58-L63

The Actor Stack’s transaction wrapper creates a nested transaction. If we aim to keep the stack wrapped in a transaction, there are two possible behaviors:

• default: the minter’s nested transaction is a part of the parent (actor stack) transaction. this is what is happening now.
• requires_new: true: the nested transaction is treated as a check point. if it the minter transaction fails, the actor stack transaction may still succeed without it. in this case, the nested transaction still does not succeed when the parent transaction fails. i have tested this with sqllite3.

As far as I can tell, there’s just no way to make a sub-transaction succeed independent of its parent.

Increasingly, I’m convinced that making the stack transactional is just a bad idea. Unless we can neatly couple them with robust rollback of ActiveFedora changes, it seems better to let the database collect cruft along with Fedora/Solr. @orangewolf: if you have an in-development app you are currently working with, I might suggest you remove the TransactionalRequest actor and see if that introduces new problems for you.

The other issue is that we’re still not making any progress on identifying the causes of the Stack failures. Within the stack, this issue should only happen when a Work has been successfully created, but some other failure has blown up the stack. This is really nasty behavior, however the transactionality is handled. This is why I’m eager to see reproducible errors. It would be best if we could identify the kinds of env states that give rise to this and reject them much earlier in the creation process.

I haven’t been able to reproduce locally, and I’m still not clear on whether you’re able to successfully mint new ids outside of the actor stack.

Could you post the output of: [::Noid::Rails::Service.new.minter.mint, ::Noid::Rails::Service.new.minter.mint]

Also, that LibreOffice is implicated suggests that derivatives jobs are running inline. Have you setup a production job queuing system (you can check with: ActiveJob::Base.queue_adapter). See also: https://github.com/samvera/hyrax/wiki/Background-Workers. This is unrelated to the minter issue, but may be a serious issue in your production configuration besides.