Travis builds failing posts.cached_version does not exist

I’ve got 3 plugins that I’m doing proper travis builds for that all started failing yesterday. They are all failing like this, and I don’t see how this problem could be caused by the plugins:

020-05-01 00:29:58.212 UTC [334] ERROR:  column posts.cached_version does not exist at character 193
2020-05-01 00:29:58.212 UTC [334] HINT:  Perhaps you meant to reference the column "posts.baked_version".
2020-05-01 00:29:58.212 UTC [334] STATEMENT:  SELECT "posts"."id", "posts"."user_id", "posts"."topic_id", "posts"."post_number", "posts"."raw", "posts"."cooked", "posts"."created_at", "posts"."updated_at", "posts"."reply_to_post_number", "posts"."cached_version", "posts"."reply_count", "posts"."quote_count", "posts"."deleted_at", "posts"."off_topic_count", "posts"."like_count", "posts"."incoming_link_count", "posts"."bookmark_count", "posts"."score", "posts"."reads", "posts"."post_type", "posts"."vote_count", "posts"."sort_order", "posts"."last_editor_id", "posts"."hidden", "posts"."hidden_reason_id", "posts"."notify_moderators_count", "posts"."spam_count", "posts"."illegal_count", "posts"."inappropriate_count", "posts"."last_version_at", "posts"."user_deleted", "posts"."reply_to_user_id", "posts"."percent_rank", "posts"."notify_user_count", "posts"."like_score", "posts"."deleted_by_id" FROM "posts" WHERE ("posts"."deleted_at" IS NULL) AND 1=0
PG::UndefinedColumn: ERROR:  column posts.cached_version does not exist
LINE 1: ...ts"."updated_at", "posts"."reply_to_post_number", "posts"."c...

I just upgraded a site and it worked fine, so it’s not something affecting sites working properly.

I just tried again (it’s been 14 hours!) and it looks like the problem persists. Is there something that I need to update?

https://travis-ci.org/github/pfaffman/discourse-topic-default-tag
https://travis-ci.org/github/literatecomputing/discourse-prometheus
https://travis-ci.org/github/pfaffman/discourse-allow-pm-to-staff

2 Likes

So this is what you are referring to? Did we remove that column?I remember @sam removing some columns recently.

Many years ago

Are any of these plugins unofficial? Are you installing an old version of calendar?

They’re all unofficial, else, I’d not be testing them. :wink:

Sorry if that wasn’t clear.

These have all been passing all tests for some . . . weeks at least. There was some time a while back that they failed tests for a few days and then started working again a few days later.

None of them is doing anything with calendar that I know of. this one is fairly trivial if you want to have a look.

1 Like

Do any of them have migrations?

1 Like

Nope. I have no idea how to have them do migrations. :wink:

So, it got better. 14 hours ago, https://travis-ci.org/ re-ran for my custom plugins and they all passed. I didn’t change anything. This has happened at least once before where travis builds failed and a few days later they started passing again without my doing anything.

3 Likes

I’m getting the same issue while running migrations with our discourse-ratings plugin alone with a vanilla dev setup. I don’t see any code which specifically asks for cached_version column.

commit hash: 093ee1d80c269afd00ba1341a3e71eb97e4ce7f1

I ran RAILS_ENV=test rake db:drop db:create db:migrate so there should be no data in the db.

This is the line

1 Like

Ok, this is what worked for us. We called reset_column_information on the relevant tables before the migration. Somehow, the cached_version column is cached :wink: in the schema cache. Also, this seems to be an issue particularly in test environment.

https://apidock.com/rails/ActiveRecord/Base/reset_column_information/class

3 Likes