Graphql-engine: Enum Not Added To Schema

[jcmoore0]

Problem: Enums are not updating v1.1.0-beta.2

Details/ Steps to Reproduce:

New Enum

1. Change table to enum
   Go to Docs -> no enum found for table

Change Enum

1. Add row to existing enum table.
2. Press 'reload enum values'
   Go to Docs -> no additional enum found for table

[lexi-lambda]

Thanks for the report! I think I know what’s causing this—we added some additional caching to the metadata reloading process, and it’s being a little too aggressive for enum tables (the enum values aren’t technically part of the metadata, so it thinks the table “didn’t change” and skips reprocessing it). The fix should be easy.

[jcmoore0]

Hi @lexi-lambda - I am still having issues with the new v1.1.0-beta.3 release.

'reload enum values' - intermittently works ~20% time
'make table an enum' - doesn't work after many tries

Thanks for the help.
Best regards,

[lexi-lambda]

@jcmoore0 Could you say more about what you’re seeing? Are you getting any errors, or is there just no effect whatsoever?

[jcmoore0]

@lexi-lambda - I don't get any errors. It's just not changing the schema.
Thanks,
John

[jcmoore0]

Hi @lexi-lambda - I just realized the schema will not include enum until a relationship is created to an enum table.

Update:
'reload enum values' - intermittently works ~20% time -> restart server as a work around
'make table an enum' - works -> need to create a relationship to the enum table first

Thanks for the help.
Best regards,

[mirzap]

Still a problem in v1.2.0-beta.2
After adding a new value to the enum table, I reloaded enum values multiple times but still metadata wasn't updated. I get following err:

graphql-engine_1  | Spock Error while handling ["v1","query"]: expected one of the values "en", "de" for type "settings_locales", given "fr"

fr is a new value in enum table.

Restarting hasura server helped.

[fbrbovic]

I am experiencing the same problem, no matter how many times I reload it, new values don't show up.
Will try restarting the server.

[lexi-lambda]

It would be very helpful if you should share a schema that reproduces the issue! Otherwise it’s hard to know what’s going on.

[jcmoore0]

Hi @lexi-lambda - 'Reload enum values' doesn't update schema. It's not super urgent since there is a workaround by restarting the server.

I just ran a simple test and included migrations here:
https://github.com/jcmoore0/hasura_enum

Let me know if you need something else.

Best regards,

[lexi-lambda]

Thanks, that’s extremely helpful! I can’t promise that we’ll look into it immediately, but I’ll definitely make sure it gets looked at in the near future.

[mirzap]

This seems to be fixed with latest release (v1.2.0-beta.3)
After clicking "reload enum values" metadata is updated correctly and there's no need to restart hasura server anymore.

Thanks! 🙏

[jcmoore0]

Confirmed fix. Thanks, great job.

[kurt-o-sys]

It's still not updated here, I'm running hasura 1.2.1.
After adding new values, I can't use the new values in insert operations.
If I query the enum field using the graphiql/api-explorer, the new values are there.

Switching off and 'Set table as enum' does reload the values.

In any case, if there's a button 'reload values, it should work :).

[BlueSeph28]

The same happens here! Hasura 1.1.1,
I insert some values, click to "reload values" and doens't work

I do the "switching off and 'Set table as enum'" workaround and it works!

[pronevich]

v1.2.2 the same issue. @marionschleifer it's more than half year for pretty serious bug )

[nomocas]

Hi All, Same issue on Hasura 1.3.

[andycmaj]

i believe that might be what's causing this as well:

running same query multiple times (with an enum_userOnboardingStatus_enum_comparison_exp) returns failure about 50% of the time.

this was after a migration that added a new enum value.

i force-restarted all of my hasura instances, and this problem went away completely. so yes. seems like caching is the issue.

this is on 1.3.0 running 2 dynos on heroku.

[Nomad-Go]

Still having this problem on version 1.3.2 had to "force new deployment" on my AWS ECS Service. I tried both reloading the enum table and reloading all metadata.

[MarkNBroadhead]

Having issue on Hasura 1.3.2. Brand new docker container & database, schema not updating when new enums are added to database table.

[bgold0]

This is happening to me on Hasura Cloud. I literally can't update my application because of this bug.

[lexi-lambda]

I finally got to looking into this, and I’m afraid to say I still cannot reproduce this on my machine. :slightly_frowning_face: I tried following the steps in https://github.com/hasura/graphql-engine/issues/3759#issuecomment-603013180 a few times against graphql-engine v1.3.2, but every time I pressed “Reload Enum Values,” I saw the schema immediately update.

This is frustrating, because obviously the issue is happening for several people. I am definitely not denying that! But I have no idea what could possibly be going wrong, and without being able to reproduce the problem, I am not sure how to proceed.

Here are the full details of my environment:

• HGE: hasura/graphql-engine:v1.3.2
• Postgres: 12.4
• OS: Ubuntu 18.04 Bionic
• Docker: 19.03.13

If anyone can provide an environment that consistently reproduces this issue, I’d be much obliged. In the meantime, I’m afraid I’m at something of a loss.

[pronevich]

Hi, @lexi-lambda here is the reproduction:

1. I created new project in Hasura Cloud.
2. Created in console SQL:

CREATE TABLE test_enum (
  val text PRIMARY KEY,
  description text
);

INSERT INTO test_enum (val, description) VALUES
  ('FIRST', 'First test enum val'),
  ('SECOND', 'Second test enum val');

1. Created in console SQL. type - ref to test_enum

CREATE TABLE use_enum (
  id int GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
  type text NOT NULL REFERENCES test_enum
);

INSERT INTO use_enum (type) VALUES
  ('FIRST'),
  ('SECOND');

1. Set table as enum
2. Update enum value FIRST to FIRST_UPD
3. Reload enum values
   
4. Test if enum value was changed in schema - NO
   

[lexi-lambda]

Good news: with the help of both the comments on this issue and some investigation by a couple other folks on the team, I finally managed to consistently reproduce the issue on my machine. PR #6027 has the fix, which should hopefully finally resolve this problem for good once merged. Thank you all for your patience!