If DuplicatePstatement will happen once, activerecord goes into DuplicatePstatement loop

[stenver]

We started seeing this issue in the logs:

#<ActiveRecord::StatementInvalid: PG::DuplicatePstatement: ERROR:  prepared statement "a22092" already exists
: INSERT INTO "locations" ("city", "country_code", "country", "state", "visit_id") VALUES ($1, $2, $3, $4, $5) RETURNING "id">
/home/deployer/services/visit_registry/shared/bundle/ruby/2.2.0/gems/activerecord-4.2.0/lib/active_record/connection_adapters/postgresql_adapter.rb:637:in `prepare'
/home/deployer/services/visit_registry/shared/bundle/ruby/2.2.0/gems/activerecord-4.2.0/lib/active_record/connection_adapters/postgresql_adapter.rb:637:in `prepare_statement'

Digging deeper, I found this piece of code:

https://github.com/rails/rails/blob/master/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb#L625

Basically, if the @connection.prepare nextkey, sql fails for some reason, then the nextkey will not get saved.

If the failure was because of DuplicatePstatement, this will become a problem, as subsequent prepared statement to also fail due to having an existing statement name.

[LcpMarvel]

+1

[ivanreese]

If I understand correctly, this was explored in depth in #17607. The outcome seems to be that issue is most commonly caused by the rack-timeout gem, which is pretty nasty in that it can raise an exception at nearly any time. The Rails core team don't seem inclined to code the framework to defend against having the carpet pulled out from under them at any moment, which is totally reasonable. Heroku (who made rack-timeout) can't really do anything to handle this on their side — rack-timeout is intended to be a "last resort" defence against your app going totally unresponsive. So the burden falls to app developers to try especially hard to avoid hitting that timeout.

I don't think there's a clean solution to this problem at this time, based on all my reading so far.

[rails-bot]

This issue has been automatically marked as stale because it has not been commented on for at least
three months.

The resources of the Rails team are limited, and so we are asking for your help.

If you can still reproduce this error on the 5-0-stable branch or on master,
please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions.

[rails-bot]

This issue has been automatically closed because of inactivity.

If you can still reproduce this error on the 5-0-stable branch or on master,
please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions.

[ricardovj]

Hey guys, is anyone else experiencing this issue? We're running into this exact error every couple of weeks, we're on rails 6, ruby 2.7.

[ko-lem]

Hey guys, is anyone else experiencing this issue? We're running into this exact error every couple of weeks, we're on rails 6, ruby 2.7.

Same here. I just restart dynos if I'm up when it happens, like now. Don't know what else to do.

[rafaelfranca]

This is now fixed in 6-1-stable

[kbighorse]

I have seen this issue on Rails 5.2.x, was the 6.1 fix backported to Rails 5?

[seanlinsley]

I'm guessing #41356 is the change that fixed this issue. (just linking them together – I haven't confirmed yet)