New Card Saving Issue (v0.33.4)

We have just upgraded to 0.33.4 and migrated our config database. We have all of the expected functionality. We are able to edit and save existing cards but not create and save new ones …

Is anyone seeing similar behaviour on this new version?

I just tried migrating a 0.32.10 database to 0.33.4 and can’t reproduce this. Did you see any migration errors in your server logs when starting up 0.33.4 for the first time? What type of database are you trying to query? Are you seeing any JavaScript console errors or server errors when you try to save? What happens on the screen?

We are using a postgres db and didn’t see any errors when starting up.

We see the following logs when trying to save a new card:

[4df59e9a-c035-4191-8bb9-c252a483c5bd] 2019-10-09T18:17:19+01:00 INFO metabase.api.card Card results metadata passed in to API is VALID. Thanks!
[4df59e9a-c035-4191-8bb9-c252a483c5bd] 2019-10-09T18:17:19+01:00 DEBUG metabase.async.util Running metabase.api.card$save_new_card_async_BANG_$fn__60472@40f6b8c4 on separate thread...
[4df59e9a-c035-4191-8bb9-c252a483c5bd] 2019-10-09T18:17:19+01:00 DEBUG metabase.middleware.log POST /api/card 200 [ASYNC: completed] 108.8 ms (36 DB calls) Jetty threads: 2/50 (5 idle, 0 queued) (161 total active threads) Queries in flight: 0
[4df59e9a-c035-4191-8bb9-c252a483c5bd] 2019-10-09T18:17:19+01:00 ERROR metabase.async.util Caught error running metabase.api.card$save_new_card_async_BANG_$fn__60472@40f6b8c4

This is what we see on screen:

Thanks for the additional info. Can you also tell me which version of Metabase you upgraded from? And is this happening when trying to save any question? Can you save SQL questions but not GUI ones (or vice versa)? Can you save questions based on the sample dataset?

I’ve also opened this github issue to track your bug:

Thanks Maz!

I migrated the backend from a postgres db running v0.32.8 onto a new postgres db and immediately onto the latest Metabase version. Should I retry the migration to the same version before upgrading?

We were seeing issues with the PK on the query_execution and view_log tables after the migration. Metabase was not recognising the sequencing and therefore trying to enter new rows that were conflicting with existing PK identifiers. (truncating the tables got over this issue).

We are seeing this saving issue on both GUI and SQL editor for both existing db connections as well as new ones. I can confirm we are able to edit and save existing content, just not create new ones.

Thank you for opening that bug :smile:

We found that this error was being driven by the Postgres sequence not recognising the existing values in a table and therefore conflicting with unique constraints.

I used the following combinations to replace the sequences:

SELECT MAX(id) + 1 FROM report_card;
ALTER TABLE report_card ALTER COLUMN id SET DEFAULT nextval('card_id_seq');

This fix would likely have worked for the two other tables we truncated.

I hope this is helpful for anyone else :smile:


I believe the issue here is this:

I migrated the backend from a postgres db running v0.32.8 onto a new postgres db

When Metabase creates new Cards, it doesn’t specify what the new ID should be. Instead, if relies on the database itself to provide a default value.

In postgres, this is accomplished by using the report_card_id_seq sequence. As @Kieran_m noted, you use nextval('report_card_id_seq') to get the value of the sequence and increment it. This value is managed by the database, not metabase.

If you started using a fresh postgres db, then in all likelihood the report_card_id_seq sequence was starting with the value 1, rather than the maximum id value (946 in your case). This is why postgres was producing id values that were already “taken.”

The reason why @Kieran_m’s fix worked is that it created a new sequence, card_id_seq, and used that to generate new values for id. My guess is it would also have worked to run this:

ALTER SEQUENCE report_card_id_seq RESTART WITH 946;

There are two things we can do here (that I can think of):

  • As @maz suggested, report the error in the UI
  • If we provide tools to move the metabase data to a new database, make sure they preserve this sequence info