CODEWITHSUNDEEP
ruby-on-rails
Starkers
Starkers

Reputation: 10541

Explain this ActiveRecord error

PG::InFailedSqlTransaction: ERROR: current transaction is aborted, commands ignored until end of transaction block : SELECT "discussions".* FROM "discussions" WHERE "discussions"."id" = $1 ORDER BY "discussions"."id" ASC LIMIT 1

What does that error actually mean in plain English?

Here's the code that causes the error:

self.discussion.forum.update_attributes(reply_count: self.discussion.forum.reply_count + 1 )

Why do you think this would cause an error on the server but not locally? I've run in production and development modes locally and not a hint of this problem occurs. On the server, it returns this error.

On the server:

git log
commit d41d8cd98f00b204e9800998ecf8427e
git status
# On branch master
nothing to commit, working directory clean

Locally:

git log
commit d41d8cd98f00b204e9800998ecf8427e
git status
# On branch master
nothing to commit, working directory clean

It's all so identical I want to scream.

All I can think is that it must be something in the database, but I have no idea what or why it would cause such an error...

Worth noting that the whole application is interacting with the database perfectly, apart from that one line of code that causes the error. So odd.

Update:

I've fixed the error my restarting my puma application server. Which is great, but I don't understand this error at all. If someone could enlighten me so this problem doesn't appear randomly again while the app is live I would be very grateful.

Upvotes: 0

Views: 108

Answers (1)

tompave
tompave

Reputation: 12412

The error message doesn't provide any details. It just says that a SQL transaction has failed. This could be translated with:

I was trying to execute a list of actions in a precise sequence, but one has failed and I'm aborting and reverting the entire sequence

This IS the expected behaviour of SQL transactions.

For what concerns the specific error, the message doesn't say. You should look at the error backtrace, and see which other files (and lines) are involved.

On why restarting Puma solved it

You probably had not restarted Puma yet, and it was still running the previous version of your application (regardless of the commit the Ruby files were at). Maybe you had already run the DB migrations on the server, and so there was a mismatch between the tables in the DB and the models loaded in the running copy of the app.

Upvotes: 1

Related Questions