Travis builds failing posts.cached_version does not exist

Dev
1

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
2

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

3

Many years ago

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

4

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
5

Do any of them have migrations?

1 Like
6

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

7

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
8

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
https://github.com/paviliondev/discourse-ratings/blob/76ec8e20754070be593503d45e25b789c002537b/db/migrate/20200520084648_add_rating_types.rb#L6

1 Like
9

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