Is it correct to use the :identifier key here, or should we instead be using :value? For example, I have this enum definition:

enum :purchase_payment_status do
  value(:paid, as: :purchase_payment_status_paid)
end

In that example, :paid corresponds to the external value of the enum, "PAID". With my chosen value as: :purchase_payment_status_paid, I assumed I was supposed to provide something totally unique that I could reference during hydration. However, when hydrate gets called, it gets called with:

[2] %Elixir.Absinthe.Blueprint.Schema.EnumValueDefinition{
    __reference__: %{
      location: %{
        file: "/MyApp/web/graphql/schema_types/purchase.ex"
        line: 12
      }
      module: :Elixir.MyApp.GraphQL.Schema.Types.Purchase
    }
    deprecation: nil
    description: "The purchase has not yet been paid"
    directives: []
    errors: []
    flags: %{}
    identifier: :not_paid
    module: :Elixir.MyApp.GraphQL.Schema.Types.Purchase
    name: "NOT_PAID"
    source_location: nil
    value: :purchase_payment_status_not_paid
  }

In that example it is :value that I actually want to match against in order to convert to its true internal value, "Not Paid", which I pull in from a function in another module during hydrate:

def hydrate(%Absinthe.Blueprint.Schema.EnumValueDefinition{value: value} = enum, [])
    when value in [:purchase_payment_status_not_paid] do
  {:as, MyApp.GraphQL.Schema.Types.Purchase.payment_status(value)}
end

Asking here for a few reasons:

1. In case we might want to alter the test to reflect different recommended usage
2. In case we want to alter any docs to reflect this
3. In case somebody else runs into a similar issue and this example is helpful to them.

It's just an example, people could do it whatever way works best for them...

Though the whole point is to assign the :as value, so already having one set will just overwrite it (ie: why set that at all in the schema?)

Seems like you have 3 "layers" of enum values going on here, which I don't think would be so common?

Yeah, I can see how it might be less common. In this case, the external value :paid/"PAID" is not something that I would be confident would be unique across all of our enums, so I don't feel confident matching on that in hydrate because it might conflict with another value (say the same value on Order status, or Invoice status).

I haven't seen any GraphQL convention that advocates making all of your enums have globally unique values, so this seems like what's necessary to avoid a potential collision 🤷‍♂ Anyway, will assume this is a rarer use case and leave it at that, thanks @binaryseed ✌️

I haven't seen any GraphQL convention that advocates making all of your enums have globally unique values, so this seems like what's necessary to avoid a potential collision

The normal solution here is that the hydrate function should be passed a list as the second arg of the parent values indicating where in the schema "tree" we are. This would allow you to pattern match for a particular enum value definition found under a specific enum definition. However @binaryseed I'm noticing that the second arg in your test case is an empty list. Am if misremembering how hydrate works or are we losing context for some reason?

yeah I noticed that too - it works currently, but i'm making a PR that matches on the ancestors since thats what we should be doing

#871