I went for a hybrid approach where

1. resources’ IDs passed directly as arguments are processed by a middleware which attempts to fetch the resource and puts it in the context, or adds an error (in errors). Example:

field :create_foo, :create_or_update_foo_result do
  arg :input, non_null(:foo_input)
  arg :organization_id, non_null(:id)

  middleware Middleware.HandleNotFoundError,
    arg: :organization_id,
    context_key: :organization,
    fetcher: &MyContext.get_organization(&2.current_user, &1)

  resolve(&Resolvers.MyContext.create_foo/3)
end

I can then access the organization in this example from the context.

2. IDs passed in the attrs map for the context (:input object above) are handled by foreign_key_constraint/3 when building the changeset, and I return to the client either changeset errors (in data) or a specialized object like BarNotFound { id }.

And this is where it’s really, really nice to work with soft deletes where I do not have to return nice errors to the client in case there is a foreign key error and deal with annoying questions related to concurrent fetch/delete operations driving one’s crazy (with soft deletes, foreign key errors would only be coming from either a malicious user trying to change the IDs or from a programmer bug).