Hi folks! Thanks for creating and maintaining an awesome library. I debated opening an issue for this first, but decided it's a simple enough change that I would just create a PR. I'm happy to rework it or scrap it if that's what's decided.

Currently whenever the async or batch middleware is used, any logger metadata is lost when the new async tasks are created. This means that the Phoenix request ID doesn't show in log lines if using Phoenix, and it means that a user ID or other metadata needs to be added in every resolver to be present for logs.

This copies the logger metadata from the parent process whenever a new async task is created so that any logs further down the stack will have access to it.

Thanks for reviewing! I look forward to any feedback 😄

I don't think this is something we should do in Absinthe. I am advocating for a general context propagation solution in erlang

I also realized that you can do this much easier yourself.. the Async middleware can take in a task you've defined yourself, so you can take this example and tweak it just a bit:

https://github.com/absinthe-graphql/absinthe/blob/d83a1ff439f9d52575e34940df492528738d038a/test/absinthe/middleware/async_test.exs#L41-L50

I think something's up with how i tested it. the solution above does seem to work somehow, although only Boo.B gets recompiled somehow but not A. :confu

> iex -S mix
Erlang/OTP 23 [erts-11.1.5] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [hipe]

Interactive Elixir (1.11.3) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> A.Compiled.__absinthe_type__(:new_type) == nil
false
iex(2)> recompile
Compiling 1 file (.ex)
:ok
iex(3)> A.Compiled.__absinthe_type__(:new_type) == nil
true

Released in 1.5.4

This PR wires up the ability to set complexity settings via put_options

@benwilson512 These make sense to set on a per-request basis, but I'm not sure if the other options do...

closes #241

Hello! 👋 First of all, thank you for Absinthe and Absinthe.Plug!

I'm wondering if the maintainers would be open to the addition of a feature to dynamically determine the max complexity per query. I'd like to be able to say something like, "User X made a query, they have Y complexity allowance left, will I allow them to make this query?"

Of course this doesn't match the primary use case. 😄

Whereas the current API looks like this:

plug Absinthe.Plug,
  schema: MyAppWeb.Schema,
  analyze_complexity: true,
  max_complexity: 50

I would like to propose expanding the API to support this as well:

plug Absinthe.Plug,
  schema: MyAppWeb.Schema,
  analyze_complexity: true,
  max_complexity: &MyModule.max_complexity/1

Where &MyModule.max_complexity/1 is a function that is given the context and query and returns back an integer.

Thank you for considering! I would be glad to whip up a PR if you're open to this. Cheers!

Ok, wired it up, mind giving it a quick review?

Ah, just added import_types Boo.{B} # Note that the {} is required

Steps:

1. Make schema A import types from module B
2. Compile and run your app with an iex shell open
3. Add a new type to schema B called :new_type
4. type recompile into the iex shell
5. Run A.Compiled.__absinthe_type__(:new_type) which should return a non nil value. BUT it returns nil!

FYI a little related - there's been other conversation about default_value / nil: https://github.com/absinthe-graphql/absinthe/issues/656

@benwilson512 Thoughts on this issue?

Literal null default values in arguments in the SDL notation triggered errors.

• A pattern match was missing for the Language.NullValue when converting to Blueprint.Schema.InputValueDefinition
• In the SDL rendered the Blueprint.Input.Null was not matched when in render_value

Thanks!

This changes the relatively unhelpful message we have today:

** (Absinthe.SerializationError) Value 1.0 is not a valid integer

into something that actually tells you what field to go look for to fix the issue:

** (Absinthe.SerializationError) Could not serialize term 1.0 as type Int
When serializing the field:
RootQueryType.bad_integer (/path/to/schema/module.ex:8)

The only tricky bit is the lack of a PR # before submitting :)

I believe that we have encountered a bug with the ParseIDs middleware and it may be related to #72

I have a definition that roughly mirrors this:

  input_object(:post_comments_input) do
    field(:posted_by_user_id, :id)
  end

  connection(:comments, node_type: :comment) do
    field(:total_count, non_null(:integer), resolve: &count_resolver/3)
    edge(do: nil)
  end

  node object(:comment) do
    field(:body, non_null(:string))
  end

  node object(:post) do
    connection field(:comments, node_type: :comments) do
      # I like to put query args in an input object because I can deprecate the fields
      arg(:input, :post_comments_input)

      # This is the problem area when calling updatePost
      middleware(Absinthe.Relay.Node.ParseIDs, input: [posted_by_user_id: :user])
      resolve(&resolve_it/2)
    end
  end

  payload field(:update_post) do
    middleware(Absinthe.Relay.Node.ParseIDs, post_id: :post)

    input do
      field(:post_id, :id)
      field(:body, :string)
    end

    output do
      field(:post, non_null(:post))
    end

    reslovlve(&upate_it/2)
  end

When I call the node query with posts there are no problems:

  query TestQuery($input:PostCommentsInput,$id:ID!) {
    post: node(id:$id) {
      ... on Post {
        comments(first:0,input:$input) {
          totalCount
        }
      }
    }
  }

The problem I am seeing happens when I use the updatePost mutation and then resolve the Post.comments connection like so:

  mutation TestMutation($input:UpdatePostInput!) {
    updatePost(input:$input) {
      post {
        comments(first:0) {
          totalCount
        }
      }
    }
  }

I get an error returned that states:

{
  "data": {
    "updatePost": {
      "post": {
        "comments": null
      }
    }
  },
  "errors": [
    {
      "message": "Could not find schema_node for input",
      "path": [
        "updatePost",
        "post",
        "comments"
      ]
    }
  ]
}

I have circumvented this problem by not using the ParseIDs middleware and manually parsing the IDs, but it is not a scalable solution. I am planning to write custom middleware for this scenario, but I'd rather not. It seems like something ParseIDs should support.

Let me know if I can help clarify this any further. I know it is not a typical use-case. Thank you!

Thanks!

Not sure where the project list link should go to, but the current location results in a 404.

Not sure where the project list link should go to, but the current location results in a 404.