profile
viewpoint

reactjs/react-rails 6095

Integrate React.js with Rails views and controllers, the asset pipeline, or webpacker.

rmosolgo/acorn 9

🚧 State Machine Compiler for Crystal

rmosolgo/batfire 5

Firebase bindings for batman.js

rmosolgo/batman-rails-flo 4

Live reloading batman.js with Ruby on Rails

rmosolgo/batmanjs-mvc-cookbook 4

A Softcover.io project for batman.js recipes

rmosolgo/bramble 4

Map-Reduce for Rails, ActiveJob and Redis

rmosolgo/bootstrap-teaser 3

Paragraph preview/teaser for Twitter Bootstrap/jQuery

rmosolgo/aiddata-bootswatch 2

Bootstrap in AidData Blue

rmosolgo/cancanpreload 2

Test app with graphql-preload and CanCan auth

rmosolgo/aiddata-codes 1

Sector Codes API

issue commentrmosolgo/graphql-ruby

Raise type-specific errors for better bug tracker integration

Hi @Fadi25 , could you please share the full stack trace that you got with that error?

If it happened in a resolver or field, then the stack trace would include that info.

rmosolgo

comment created time in 15 hours

issue commentrmosolgo/graphql-ruby

"uninitialized constant GraphQL::StaticValidation::Message" Error. Bug in GraphQL version comparison

Sorry for the hangup! This check was improved back in graphql-pro v1.11.0. Can you upgrade to that version and see if it fixes it for you?

If you're not able to upgrade for some reason, please let me know. Either we'll find a solution, or I'll patch 1.9.9 and cut a new release.

kryptonat

comment created time in a day

push eventrmosolgo/graphql-ruby

Joel Turkel

commit sha 38b1f230c98cd52efaeb96d09531adc28eae39c8

Load deprecation reason from introspection results

view details

Robert Mosolgo

commit sha 9c4b7ebbdcbd32885a80bc813a50fd12e1817e14

Merge pull request #3014 from jturkel/feature/deprecations-from-introspection Load deprecation reason from introspection results

view details

push time in a day

PR merged rmosolgo/graphql-ruby

Load deprecation reason from introspection results

This PR updates GraphQL::Schema.from_introspection to load field and enum value deprecation reasons from introspection results. I converted spec/graphql/schema/loader_spec.rb to use the not so new anymore class based API while I was adding test coverage.

+132 -125

1 comment

2 changed files

jturkel

pr closed time in a day

pull request commentrmosolgo/graphql-ruby

Load deprecation reason from introspection results

Thanks for the fix and the test upgrade!

jturkel

comment created time in a day

issue commentkhiav223577/deep_pluck

Could this be used with GraphQL?

I think it would be an awesome thing to look into! It's always been "theoretically possible" but I haven't heard of anyone who actually worked it out. Please share your results if you get something working!

vfonic

comment created time in 2 days

startedDmitryTsepelev/rubocop-graphql

started time in 4 days

issue commentrmosolgo/graphql-ruby

Error message doesn't show for invalid cursor that has 8 characters

😱 That's so wild. Thanks for the detailed bug report.

olichka12

comment created time in 9 days

delete branch rmosolgo/graphql-ruby

delete branch : fix-argument-caching

delete time in 10 days

push eventrmosolgo/graphql-ruby

Scott Walkinshaw

commit sha 895a025d3f284936c3e35a8dcb38556aa56b760d

Fix arguments caching - checking for extensions Previously this only checked for field extras but field extensions should be checked as well since they can mutate arguments.

view details

Robert Mosolgo

commit sha eb15f0333a97357af6c6180800874ee37a5be187

Merge pull request #3009 from rmosolgo/fix-argument-caching Fix arguments caching - checking for extensions

view details

push time in 10 days

PR merged rmosolgo/graphql-ruby

Fix arguments caching - checking for extensions

Previously this only checked for field extras but field extensions should be checked as well since they can mutate arguments.

+3 -2

0 comment

1 changed file

rmosolgo

pr closed time in 10 days

pull request commentrmosolgo/graphql-ruby

Lookahead#selects? not matching fragment/type fields

Hey, yes, you've understood correctly, it's a bug! Do you want to take a crack at fixing it in this PR?

RobinDaugherty

comment created time in 10 days

PR opened rmosolgo/graphql-ruby

Fix arguments caching - checking for extensions

Previously this only checked for field extras but field extensions should be checked as well since they can mutate arguments.

+3 -2

0 comment

1 changed file

pr created time in 10 days

create barnchrmosolgo/graphql-ruby

branch : fix-argument-caching

created branch time in 10 days

push eventrmosolgo/graphql-ruby

Robert Mosolgo

commit sha 949909acf9dbe128e84a4901bbe43d7210cec96b

Add missing checksum

view details

push time in 10 days

created tagrmosolgo/graphql-ruby

tagv1.10.14

Ruby implementation of GraphQL

created time in 10 days

push eventrmosolgo/graphql-ruby

Robert Mosolgo

commit sha e66b7690b793741d64caf62f073ee2ac2f01d911

1.10.14

view details

push time in 10 days

issue commentrmosolgo/graphql-ruby

Generates an incorrect schema with invalid enum values

Thanks for the heads up! I agree we should validate that ahead of time.

We actually have a regexp for this:

https://github.com/rmosolgo/graphql-ruby/blob/defcac5896427849fa2f3e56d326bfac389b7718/lib/graphql/name_validator.rb#L4-L8

but it hasn't been applied to the (relatively-new) class-based schema code yet. I think it could be added to https://github.com/rmosolgo/graphql-ruby/blob/master/lib/graphql/schema/enum_value.rb, maybe by:

  • Adding the validation to def value(new_value)
  • And updating def initialize to call self.value(new_value) instead of assigning @value = directly (that way, both codepaths get the validation)

Feel free to give it a shot if you get a chance! Otherwise I'll try to make time for it soon.

qortex

comment created time in 10 days

issue commentrmosolgo/graphql-ruby

[Pro] Authorize model attributes with can? and hide schema objects

I've just released graphql-pro 1.14.1 which adds a can_can_attribute: configuration. You can find the docs for it (as well as a suggestions for adding a default value, like you described) here: https://graphql-ruby.org/authorization/can_can_integration#authorizing-by-attribute

Regarding schema visibility, the best think I can think of would be to implement def self.visible? in the type classes, as described here: https://graphql-ruby.org/authorization/visibility.html

To implement an API like you described, you could do this:

class Types::BaseObject 
  # Accept the array in the class definition 
  def self.can_can_visible(config) 
    @can_can_visible_config = config 
  end 
  
  def self.visible?(context)
    if @can_can_visible_config
      # Get the memoized Ability instance from `context` (this is implemented in GraphQL-Pro)
      ability = get_can_can_ability(context)
      ability.can?(*@can_can_visible_config)
    else 
      true 
    end 
  end 
end 

(I implemented it to accept an array as shown in the original post, you might update it to take named params instead. But that's the gist of it!)

If you wanted to use that same API in other other base classes, you could extract it to a module and extend/include it in those other base classes.

Want to give it a try?

fshauge

comment created time in 10 days

push eventrmosolgo/graphql-ruby

Robert Mosolgo

commit sha defcac5896427849fa2f3e56d326bfac389b7718

pro-1.14.1

view details

push time in 10 days

issue commentrmosolgo/graphql-ruby

Arguments should prevent _both_ default_value and required: true

👋 @Diego-Thomaz, that'd be great!

Honestly, I think the best place to add this check is inside GraphQL::Schema::Argument#initialize. There, you could check the required: and default_value: keyword arguments to make sure they don't conflict.

One advantage to putting the validation there is that, when it raises an error, the application code with the invalid configuration will be present in the backtrace.

Let me know if you give it a try and there's anything I can help with!

rmosolgo

comment created time in 12 days

issue commentrmosolgo/graphql-ruby

object.parent and/or edge_class not available to custom edges

Hey, sorry about the hangup and thanks for the thorough writeup. A few things:

Regarding Edge#parent, it was added in #2961 and released in 1.11.0, you'll see it in the source here: https://github.com/rmosolgo/graphql-ruby/blob/daf2e6a87ee36460b7d3d2570bad845d96a4963c/lib/graphql/pagination/connection.rb#L200-L202

Regarding custom edge classes, yes, I think you're right that it's a bug. It looks like some docs & code need to be updated. I suppose the type-defined edge_class: should take priority over the Pagination::Connection's .edge_class.

amazing-jay

comment created time in 14 days

Pull request review commentrmosolgo/graphql-ruby

Add with_alias: option to Lookahead#selection and Lookahead#selects?

 def selected?       # Like {#selects?}, but can be used for chaining.       # It returns a null object (check with {#selected?})       # @return [GraphQL::Execution::Lookahead]-      def selection(field_name, selected_type: @selected_type, arguments: nil)-        next_field_name = normalize_name(field_name)+      def selection(field_name, selected_type: @selected_type, arguments: nil, with_alias: false)+        if !with_alias || selects?(field_name, arguments: arguments)+          next_field_name = normalize_name(field_name)+          next_field_defn = get_class_based_field(selected_type, next_field_name)+          return lookahead_for_selection(next_field_name, next_field_defn, selected_type, arguments)+        end +        return alias_selections[field_name] if alias_selections.key?(field_name)++        alias_node = lookup_alias_node(ast_nodes, field_name)+        return NULL_LOOKAHEAD unless alias_node++        next_field_name = alias_node.name         next_field_defn = get_class_based_field(selected_type, next_field_name)-        if next_field_defn-          next_nodes = []-          @ast_nodes.each do |ast_node|-            ast_node.selections.each do |selection|-              find_selected_nodes(selection, next_field_name, next_field_defn, arguments: arguments, matches: next_nodes)-            end-          end -          if next_nodes.any?-            Lookahead.new(query: @query, ast_nodes: next_nodes, field: next_field_defn, owner_type: selected_type)-          else-            NULL_LOOKAHEAD-          end-        else-          NULL_LOOKAHEAD-        end+        arguments = @query.arguments_for(alias_node, next_field_defn)+        arguments = arguments.is_a?(::GraphQL::Execution::Interpreter::Arguments) ? arguments.keyword_arguments : arguments

Sorry, I still don't quite get it. The point of arguments: here is so that the application can make optimizations when the incoming query meets certain criteria.

For example, let's say I keep reports in my document store, with attached files embedded in them. Then, if I receive a query like this:

query($withImages: Boolean!) {
  reports(first: 10) {
    # sometimes we only want the text attachments here; other times, we want text _and_ images
    attachedFiles(first: 50, includeImages: $withImages) {
      # ...
    }
  }
}

I want to know whether includeImages is true or false when I query the document store to retrieve results, so that I can efficiently query the backend. Implementation-wise, it looks like this:

field :reports, [ReportType], null: false, extras: [:lookahead] do 
  argument :first, Integer, required: true 
end 

def reports(first:, lookahead:)
  query_with_images = lookahead.selects?(:attached_files, arguments: { include_images: true })
  DocumentStore.find_reports(user: context[:current_user], first: first, include_images: query_with_images)
end 

That way, I can make the parent query more efficient by looking ahead at the arguments of the child field.

However, if arguments: is ignored, then the lookahead includes all nodes with the given field, regardless of arguments. (There's no filtering by arguments in that case.)

Now, in the implementation here, selects_alias? has a different implementation:

  • If any fields with the given alias are found, then, regardless of the given arguments:, no argument filtering is applied
  • If no fields are found with the given alias, then it tries to find a field whose proper name matches the given alias, and argument filtering is applied.

That seems inconsistent to me: why would we apply filtering in one case but not the other? Why not make selects_alias? behave the same as selects?, where it filters by arguments: when provided, but doesn't filter when arguments: isn't present?

DmitryTsepelev

comment created time in 16 days

Pull request review commentrmosolgo/graphql-ruby

Add with_alias: option to Lookahead#selection and Lookahead#selects?

 def selected?       # Like {#selects?}, but can be used for chaining.       # It returns a null object (check with {#selected?})       # @return [GraphQL::Execution::Lookahead]-      def selection(field_name, selected_type: @selected_type, arguments: nil)-        next_field_name = normalize_name(field_name)+      def selection(field_name, selected_type: @selected_type, arguments: nil, with_alias: false)+        if !with_alias || selects?(field_name, arguments: arguments)+          next_field_name = normalize_name(field_name)+          next_field_defn = get_class_based_field(selected_type, next_field_name)+          return lookahead_for_selection(next_field_name, next_field_defn, selected_type, arguments)+        end +        return alias_selections[field_name] if alias_selections.key?(field_name)++        alias_node = lookup_alias_node(ast_nodes, field_name)+        return NULL_LOOKAHEAD unless alias_node++        next_field_name = alias_node.name         next_field_defn = get_class_based_field(selected_type, next_field_name)-        if next_field_defn-          next_nodes = []-          @ast_nodes.each do |ast_node|-            ast_node.selections.each do |selection|-              find_selected_nodes(selection, next_field_name, next_field_defn, arguments: arguments, matches: next_nodes)-            end-          end -          if next_nodes.any?-            Lookahead.new(query: @query, ast_nodes: next_nodes, field: next_field_defn, owner_type: selected_type)-          else-            NULL_LOOKAHEAD-          end-        else-          NULL_LOOKAHEAD-        end+        arguments = @query.arguments_for(alias_node, next_field_defn)+        arguments = arguments.is_a?(::GraphQL::Execution::Interpreter::Arguments) ? arguments.keyword_arguments : arguments

Aaaaah, I think I finally understand what this is for. It seems like arguments: is being used to filter the selection set down to ones that match the arguments of the aliased selection.

Unfortunately that doesn't cover all possibilities allowed by the spec. For example, this is perfectly valid:

query {
  user(login: "dhh") { email } 
  dhh: user(login: "dhh") { bio }
}

What do you expect lookahead.alias_selection("dhh").selections.map(&:name) to return in that case? (I expect bio, is that right?)

I pushed a test for this case in 84c1e135b, how do you think that should behave?

DmitryTsepelev

comment created time in 16 days

Pull request review commentrmosolgo/graphql-ruby

Add with_alias: option to Lookahead#selection and Lookahead#selects?

 def initialize_node(attributes)           @alias = attributes[:alias]         end +        def alias?(val)+          self.alias == val+        end

It seems like we've added API surface area to all the nodes classes, just to avoid an explicit equality check in one case in the whole codebase. I don't think this tradeoff is worth it; could use explicitly check child.alias == name in lookahead.rb instead, please?

DmitryTsepelev

comment created time in 16 days

push eventrmosolgo/graphql-ruby

DmitryTsepelev

commit sha 04b277d86db8c9ccb9d7bed12913e6d95f9830c5

Lookahead#lookup_alias_node only looks for alias in node children

view details

DmitryTsepelev

commit sha 48951c5995d583c0ed0fb84adf48c3a06710389f

Handle fragments and cleanup specs

view details

Robert Mosolgo

commit sha 84c1e135bced91616ebd2e52a945bb1819409cb9

Add test for matching fields with different aliases

view details

push time in 16 days

pull request commentrmosolgo/graphql-ruby

Remove more visible? calls to unused arguments

:+1: Agreed that many of these are outright improvements!

swalkinshaw

comment created time in 16 days

push eventrmosolgo/graphql-ruby

Scott Walkinshaw

commit sha 281d26e1e2aa9bf03aff0f2946b912d0df5c9b6f

Remove more visible? calls to unused arguments Replaces more usages of `warden.arguments` during static validation (since they trigger `visible?` calls for all arguments on a type regardless if they are specified or not) with more selective `warden.get_argument`. https://github.com/rmosolgo/graphql-ruby/pull/2985 which fixed some of these occurrences, but not all of them. This also required additional backwards compatible work to port `get_argument` to the legacy types.

view details

Robert Mosolgo

commit sha 681eac53d6c658193c47f9424cb25e4ef1ed3d65

Merge pull request #3000 from swalkinshaw/fix-visible-calls-in-static-validation Remove more visible? calls to unused arguments

view details

push time in 16 days

PR merged rmosolgo/graphql-ruby

Reviewers
Remove more visible? calls to unused arguments

Replaces more usages of warden.arguments during static validation (since they trigger visible? calls for all arguments on a type regardless if they are specified or not) with more selective warden.get_argument.

https://github.com/rmosolgo/graphql-ruby/pull/2985 which fixed some of these occurrences, but not all of them.

This also required additional backwards compatible work to port get_argument to the legacy types.

cc @eapache @grcooper @chrisbutcher

+26 -13

3 comments

8 changed files

swalkinshaw

pr closed time in 16 days

pull request commentrmosolgo/graphql-ruby

Remove more visible? calls to unused arguments

(sorry, evidently I typed up a review here but failed to submit it yesterday!)

I'm game to include this as-is, but I'm concerned about the long-term plan here. Without tests in the gem that .visible? isn't called on arguments that aren't present, it's likely to regress. Do you plan to remove your dependency on that assumption, or should we start looking for a way to make sure that these improvements aren't accidentally lost?

swalkinshaw

comment created time in 16 days

PR merged rmosolgo/graphql-ruby

Reviewers
Fix arguments caching - check for field extensions

Previously this only checked for field extras but field extensions should be checked as well since they can mutate arguments.

@jturkel does this makes sense to you as well? I guess you didn't have any instances of field extensions mutating args?

+3 -2

5 comments

1 changed file

swalkinshaw

pr closed time in 16 days

push eventrmosolgo/graphql-ruby

Scott Walkinshaw

commit sha eb9d18f3e8bfb8a4e5d66256af00e8248f5d45fc

Fix arguments caching - checking for extensions Previously this only checked for field extras but field extensions should be checked as well since they can mutate arguments.

view details

Robert Mosolgo

commit sha 3044655d0fbfac22d301abfc306f111f1c03cebd

Merge pull request #3003 from swalkinshaw/fix-arguments-caching Fix arguments caching - check for field extensions

view details

push time in 16 days

pull request commentrmosolgo/graphql-ruby

Fix arguments caching - check for field extensions

Thanks for the great suggestion, @jturkel, I've opened an issue to keep track of that https://github.com/rmosolgo/graphql-ruby/issues/3004

swalkinshaw

comment created time in 16 days

issue openedrmosolgo/graphql-ruby

Make Interpreter::Arguments immutable

Is your feature request related to a problem? Please describe.

We want to cache arguments during execution, but it's hard to tell when field extensions will modify them. See https://github.com/rmosolgo/graphql-ruby/pull/3003

Describe the solution you'd like

Cache immutable objects; let those be copied when modified, so that the overhead isn't incurred by default.

created time in 16 days

pull request commentrmosolgo/graphql-ruby

Fix arguments caching - check for field extensions

Oh, interesting, I guess the point is, field.extras.empty? isn't enough to be sure that the arguments won't be modified.

I wonder if there's anything else on Field that could modify the arguments (Ok, it's Ruby, I'm sure the answer is yes). I guess if another one pops up, we can try to generalize about it.

swalkinshaw

comment created time in 17 days

issue commentrmosolgo/graphql-ruby

[Pro] Authorize model attributes with can? and hide schema objects

👋 Hi! Thanks for the writeup and suggestions. I think the changes are definitely feasible. Let me take a look at how they can best be implemented and I'll follow up here.

fshauge

comment created time in 17 days

issue commentrmosolgo/graphql-ruby

Batch delivery of subscription update events

I think I was wrong about the pricing difference with Pusher. In the current implementation, given n subscribers, we use 2n messages:

  • n publish calls
  • n deliveries to clients

Using a presence channel, you could use n+1 calls instead:

  • 1 publish
  • n deliveries
jacob-s-son

comment created time in 20 days

issue openedrmosolgo/graphql-ruby

Arguments should prevent _both_ default_value and required: true

I don't think there's any reason to permit default_value: and required: true, because a required argument will never apply a default value.

This was previously validated by legacy schemas, but it seems like class-based schemas aren't validating it properly.

created time in 21 days

issue closedrmosolgo/graphql-ruby

Interface/Union PossibleTypes visibility

Problem

I would like a way to change the visibility on types that Unions and Interfaces can be.

interface A {
 VALUE
}

type B implements A {
  VALUE
  FOO_VALUE
}

type C implements A {
  VALUE
  BAR_VALUE
}

There may be cases where we want to hide that type C implements A in some contexts of an API call, but still allow B to implement A for a different context. Under my current understanding, we can only control visibility of A, so either it is visible through the entire schema or not at all.

Investigation

This brought me to investigate how Warden handles Union and Interface visibilities. The common ground seemed to be https://github.com/rmosolgo/graphql-ruby/blob/master/lib/graphql/schema/warden.rb#L173 Which goes into the PossibleTypes class.

Following along with how visibility is currently implemented and to have the correct knowledge of which types to show, we need context injected somewhere here. We have it in the initializer to get the visible interfaces and could store it on PossibleTypes to return the correct types.

Questions

  1. How do we know which types to allow in (where do we expose this)
  2. Are there other places that possible types might be used
  3. Does Union's definition of possible types need to change?

Possible Solutions

  1. This can follow along with how visibility is currently implemented by providing a method like visible_types(context) which returns a list of the available types based on the context passed in. By default as to not mess with the current implementation of interfaces, it would return all possible types, but could be overridden on other interfaces.

  2. This I am not 100% sure of, but it seems that possible types are used in a few different places. The main place that I believe it will cause issues is in get_possible_types methods on interfaces and unions which checks the possible types. For those of you with more knowledge of the codebase know if there are cases where we do not have the context? Or if we need all of the known possible types and not just the visible ones?

  3. Question 2 leads into this solution, I believe that the Union's possible_types need to change, and we can then filter out visible types there, which is surfaced in PossibleTypes: https://github.com/rmosolgo/graphql-ruby/blob/master/lib/graphql/schema/possible_types.rb#L28. We already seem to have the context when using get_possible_type so this might be a better location for this visibility check?

Summary

I believe we can provide an interface similar to visible? but instead provide visible_types which only returns the types visible in the current context. This would likely live right on the InterfaceType and UnionType to be used by the PossibleTypes class.

Does this seem like a reasonable approach to this problem? Does this conflict with any current thoughts on how to change up how Warden works?

closed time in 21 days

grcooper

issue commentrmosolgo/graphql-ruby

Interface/Union PossibleTypes visibility

I think this is done! Thanks @grcooper for making this happen.

grcooper

comment created time in 21 days

issue closedrmosolgo/graphql-ruby

Need a way to inspect _sibling_ fields' lookaheads

We need some way to handle a situation like this:

... on Something {
  items {
    id 
  }
  things {
    # ... stuff 
  }
}

Where things can be optimized if items has exactly one selection, id.

This can kind of be hacked, by injecting a lookahead into every field that returns Something, and passing it down with scoped_context, but that's error-prone.

closed time in 21 days

rmosolgo

issue commentrmosolgo/graphql-ruby

Need a way to inspect _sibling_ fields' lookaheads

I'm glad you found a good solution. I haven't found the time to work on this, and since nobody else is asking for it now, I'm going to close it. Happy to dig in again later if need be.

rmosolgo

comment created time in 21 days

issue closedrmosolgo/graphql-ruby

Batch delivery of subscription update events

Currently Pusher transport implementation triggers update to every user one-by-one, which very quickly ceases to be real-time, as there is quite a delay between the first and the last subscriber. So far after discussing this with my colleague, we've decided to patch the execute_all method in the GraphQL::Pro Subscription class and prepare data for Pusher's batch_trigger. Any thoughts on this?

closed time in 21 days

jacob-s-son

issue commentrmosolgo/graphql-ruby

Batch delivery of subscription update events

Part of this was released in graphql-ruby 1.11.0 / graphql-pro 1.14.0. Since those versions, it's possible to recognize a "broadcast" and then evaluate it once and send the result to any number of subscribers. It's not exactly what's mentioned here, because it still uses n channels for n subscribers, but it's something: https://graphql-ruby.org/subscriptions/broadcast.html

I think there's still room for improvement where messages are published over the same channel, but this would be a bit tough. Currently, we use a Pusher channel for two things:

  • sending updates to subscribed clients (via publish)
  • detecting whether client is online or not (the server uses channel_vacated webhooks to delete subscriptions)

If we were going to do it over one channel, we'd need some other way to detect whether clients are online. We could use pusher presence- channels for this, but it would require authenticated all subscribed users.

The other thing is, I'm not sure what advantage it would have to use a presence- channel. It looks like Pusher bills by messages and connections, but not channels. And it looks a "message" is data delivered to a connected client, regardless of channel.

So, my takeaway is that presence- channels are not worth it: they would raise the barrier to getting started without any cost savings (or usability improvements, that I can tell).

If anyone is interested in looking into presence channels more closely, or sees some advantages that I've overlooked, please open a new issue to discuss it!

jacob-s-son

comment created time in 21 days

created tagrmosolgo/graphql-ruby

tagv1.11.1

Ruby implementation of GraphQL

created time in 22 days

push eventrmosolgo/graphql-ruby

Robert Mosolgo

commit sha daf2e6a87ee36460b7d3d2570bad845d96a4963c

1.11.1

view details

push time in 22 days

delete branch rmosolgo/graphql-ruby

delete branch : mutation-invalid-null-error

delete time in 22 days

push eventrmosolgo/graphql-ruby

Robert Mosolgo

commit sha 266aa7af37c634ca8a53ccb77d2512878b457883

Add invalid null error for mutations

view details

Robert Mosolgo

commit sha b1582f1aefd4bec91d3321ae90a984029a9f54c4

use the payload type's non-null error

view details

Robert Mosolgo

commit sha 2cb8174073d7cb4012bb65506b81c7a298da5d60

Add logging for any JS error

view details

Robert Mosolgo

commit sha d759092cd01d8a3d7a8f09e90248d1f07a38ce93

improve debug output for error class

view details

Robert Mosolgo

commit sha 35158dd142e2e91a1da05dcd8b60b43cf1df997e

Merge pull request #2997 from rmosolgo/mutation-invalid-null-error Add invalid null error for mutations

view details

push time in 22 days

issue closedrmosolgo/graphql-ruby

InvalidNullError is not defined on mutation classes

Describe the bug

class MyMutation < GraphQL::Schema::Mutation
  field :x, ..., null: false

  def resolve
     { x: nil }
  end
end

You'll get an error: uninitialized constant MyMutation::InvalidNullError

Versions

graphql version: 1.10.11 rails (or other framework): 6.0.3.1 other applicable versions (graphql-batch, etc)

GraphQL schema

Include relevant types and fields (in Ruby is best, in GraphQL IDL is ok). Are you using interpreter? Any custom instrumentation, etc?

class Product < GraphQL::Schema::Object
  field :id, ID, null: false, hash_key: :id
  # …
end

class ApplicationSchema < GraphQL::Schema
  query QueryType
  # …
end

GraphQL query

Example GraphQL query and response (if query execution is involved)

query {
  products { id title }
}
{
  "data": {
    "products": […]
  }
}

Steps to reproduce

Steps to reproduce the behavior

Expected behavior

A clear and concise description of what you expected to happen.

Actual behavior

What specifically went wrong?

Place full backtrace here (if a Ruby exception is involved):

<details> <summary>Click to view exception backtrace</summary>

Something went wrong
2.6.0/gems/graphql-1.9.17/lib/graphql/subscriptions/instrumentation.rb:34:in `after_query'
… don't hesitate to include all the rows here: they will be collapsed

</details>

Additional context

Add any other context about the problem here.

With these details, we can efficiently hunt down the bug!

closed time in 22 days

srgoldman

push eventrmosolgo/graphql-ruby

Robert Mosolgo

commit sha d759092cd01d8a3d7a8f09e90248d1f07a38ce93

improve debug output for error class

view details

push time in 22 days

push eventrmosolgo/graphql-ruby

Robert Mosolgo

commit sha da513ac4a3ad3b2d86587180474ae9f96863bc41

Add statsd docs

view details

push time in 22 days

delete branch rmosolgo/graphql-ruby

delete branch : statsd-tracing

delete time in 22 days

push eventrmosolgo/graphql-ruby

Robert Mosolgo

commit sha 58eb973dea286447832fa2997ab7a96d825e82aa

Add StatsdTracing

view details

Robert Mosolgo

commit sha e377cc269c9c0d7f62c3900a39f3ea229a6d4c3a

Dry up cached platform keys

view details

Robert Mosolgo

commit sha 43795f4d7c1da6aed321ffdf3561beca0ed92b45

Fix lint error

view details

Robert Mosolgo

commit sha 252b30afd6eead3379a9cd63970dbd26b3ca08e9

Merge pull request #2996 from rmosolgo/statsd-tracing Add Statsd tracing

view details

push time in 22 days

PR merged rmosolgo/graphql-ruby

Add Statsd tracing

Ported from GraphQL::Pro::Monitoring

+125 -15

0 comment

4 changed files

rmosolgo

pr closed time in 22 days

push eventrmosolgo/graphql-ruby

Robert Mosolgo

commit sha 2cb8174073d7cb4012bb65506b81c7a298da5d60

Add logging for any JS error

view details

push time in 22 days

push eventrmosolgo/graphql-ruby

Robert Mosolgo

commit sha b1582f1aefd4bec91d3321ae90a984029a9f54c4

use the payload type's non-null error

view details

push time in 22 days

issue closedrmosolgo/graphql-ruby

Multiple definitions error for classes that share class name but are in different modules

Describe the bug

I'm trying to hook my existing lower level Schema/typing library, into graphql, by creating custom types which do basic coercion. -- I am running into the folowing error:

Previously found Client::ExportTemplate::Fields::Kind::GraphQLObject (Class), then found Client::ExportTemplates::SurveyParticipationsExportTemplate::Fields::FieldMappings::GraphQLObject (Class) at Query.participationsExportTemplate.fieldMappings (GraphQL::Schema::DuplicateTypeNamesError)

-- So it appears that the check for duplicate type names isn't checking the fully qualified constant, but rather just the demodulized constant name and is causing it to blowup

Versions

graphql version: 1.11 rails 4.2.0):

GraphQL schema

See example type below, in which I am mapping my value objects to graphql compatible ones, as well as example base object in which it's occuring -- Note I am storing the GraphQLObject class object on the value object itself, since the namespace already exists that way and it should allow multiple fields to point to the same field while using same underlying class, since it is the same underlying class.


module Types
  class TraxStruct < Types::BaseScalar
    def self.for(klass)
      _name = "::#{klass.name}::GraphQLObject"
      _name.safe_constantize || ::Trax::Core::NamedClass.new(_name, "::Types::TraxStruct".constantize, :trax_klass => klass)
    end

    def self.coerce_input(value, _context)
      trax_klass.new(value)
    end

    def self.coerce_result(value, _context)
      value.to_hash
    end
  end
end

module Admin
  module Types
    class ParticipationsExportTemplate < ::Types::BaseObject
      description "participationsExportTemplate"
      field :kind, :type => ::Types::TraxEnum.for(::Client::ExportTemplate::Fields::Kind), null: false
      field :field_mappings, :type => ::Types::TraxStruct.for(::Client::ExportTemplates::SurveyParticipationsExportTemplate::Fields::FieldMappings), null: false
    end
  end
end

Steps to reproduce

Define two classes with the same name in different modules and you should see the error, try using them both as types and error should occur

Expected behavior

Error to not be raised

closed time in 22 days

jasonayre

issue commentrmosolgo/graphql-ruby

Multiple definitions error for classes that share class name but are in different modules

That's right -- GraphQL ruby doesn't use module namespaces by default. If you want to change that behavior, override def self.default_graphql_name in your base classes. See also https://github.com/rmosolgo/graphql-ruby/issues/1243#issuecomment-564049740

Let me know if you run into any trouble with that!

jasonayre

comment created time in 22 days

PR opened rmosolgo/graphql-ruby

Add invalid null error for mutations

Fixes #2995

+39 -10

0 comment

7 changed files

pr created time in 23 days

create barnchrmosolgo/graphql-ruby

branch : mutation-invalid-null-error

created branch time in 23 days

issue commentrmosolgo/graphql-ruby

InvalidNullError is not defined on mutation classes

Oops, thanks for the report! I guess I missed a spot in #2957

srgoldman

comment created time in 23 days

PR opened rmosolgo/graphql-ruby

Add Statsd tracing

Ported from GraphQL::Pro::Monitoring

+125 -15

0 comment

4 changed files

pr created time in 23 days

push eventrmosolgo/graphql-ruby

Robert Mosolgo

commit sha 43795f4d7c1da6aed321ffdf3561beca0ed92b45

Fix lint error

view details

push time in 23 days

create barnchrmosolgo/graphql-ruby

branch : statsd-tracing

created branch time in 23 days

issue commentrmosolgo/graphql-ruby

[Rework] Input argument validation

The other thing on my mind is, the reason for that previous PR (IIUC) is because Shopify expects .visible? to only be called for arguments which are present in the query. That expectation wasn't satisfied in 1.10.x, and still isn't, as in the case of required-but-absent arguments. We should either:

  • Continue leaving that behavior undefined in graphql-ruby, and document that there's no guarantee of when .visible? will be called;
  • Or, add tests for the expectation which was restored (-ish) in #2985, so that it's not broken in the future.

Did I understand that issue previously? How do y'all want to go forward with it?

grcooper

comment created time in 23 days

pull request commentrmosolgo/graphql-ruby

Only check used input arguments visibility

Just shipped in 1.10.13!

Thanks @grcooper for opening the followup issue. I'll add some thoughts there

grcooper

comment created time in 23 days

created tagrmosolgo/graphql-ruby

tagv1.10.13

Ruby implementation of GraphQL

created time in 23 days

push eventrmosolgo/graphql-ruby

Robert Mosolgo

commit sha 6a633f28765b5b9af90f415f02b5ae72f464831d

1.10.13

view details

push time in 23 days

push eventrmosolgo/graphql-ruby

grcooper

commit sha a7ae59687bdeeaf52f7aff3a659a3fc303128b47

Only check included and required inputs for input object validation

view details

Christopher Butcher

commit sha 342d5a39b9d68d71db11af2779e8341fe46b25d7

keep .to_h'd input, rename var to missing_required_inputs

view details

Christopher Butcher

commit sha 6a2add082dc98bdce68dbc7eb05a12ec172f95ef

Add HasArguments#get_argument

view details

Christopher Butcher

commit sha 7408d45e7e2b4cdb685d3f9ad6f3307783c09af3

Remove outdated comment

view details

Robert Mosolgo

commit sha 324aa6dd42a59fa2037b9cff2dc03cbfd8ac0711

Merge pull request #2985 from grcooper/only-check-used-input-arguments-visibility Only check used input arguments visibility

view details

push time in 23 days

PR merged rmosolgo/graphql-ruby

Only check used input arguments visibility

This line:

visible_arguments_map = warden.arguments(self).reduce({}) { |m, f| m[f.name] = f; m}

Was straightforward, but was also making visibility calls to arguments that we did not need to check.

I have sacrificed a small bit of readability here in order to reduce the number of visible? calls being made in warden.

There are three steps to this process to make sure it remained the same and didn't break tests:

  1. Inject all required arguments as nil that were missing from input. This is to satisfy this test: https://github.com/rmosolgo/graphql-ruby/blob/39b78e5e46b654d5fc9b170025e3b690e463b9e8/spec/graphql/query/executor_spec.rb#L293
  2. Check to see if the input/required args are visible on the object. Satisfies this test: https://github.com/rmosolgo/graphql-ruby/blob/39b78e5e46b654d5fc9b170025e3b690e463b9e8/spec/graphql/query/executor_spec.rb#L313
  3. Confirm that the value being provided is valid. Satisfies this test: https://github.com/rmosolgo/graphql-ruby/pull/2985/files#diff-3f549290bd93783c3126a4eeded156ceR336
+58 -15

4 comments

4 changed files

grcooper

pr closed time in 23 days

pull request commentrmosolgo/graphql-ruby

Fix issues around early disposal

🚢 1.7.11 !

jscheid

comment created time in 23 days

push eventrmosolgo/graphql-ruby

Robert Mosolgo

commit sha ec4d698f64791f90f4588c8a8cd0891e4eba7b43

js-1.7.11

view details

push time in 23 days

Pull request review commentrmosolgo/graphql-ruby

Fix issues around early disposal

 function createAblyHandler(options: AblyHandlerOptions) {         }         // When you get an update from ably, give it to Relay         channel.subscribe("update", updateHandler)++        dispatchResult(response.body)

I'll add this before publishing

jscheid

comment created time in 23 days

push eventrmosolgo/graphql-ruby

Julian Scheid

commit sha 35e55dc6b809b4534a940d702725f60d1422e827

Fix race condition in early subscription disposal

view details

Julian Scheid

commit sha 03f111fd43df3bee920ea5f6c4501afdde637eb6

Simplify subscription disposal unsubscribe without arguments "[u]nsubscribes all listeners to messages on this channel. This removes all earlier subscriptions." Also, Ably staff explained to me that "[...] you don't need to call leave() if calling detach(): the server enforces the invariant that a client cannot be present on a channel they are not attached to, so detach() will also cause that client to leave the presence set)."

view details

Julian Scheid

commit sha 1ea8059713187eaee83a92ebc615a4003e117e2c

Ensure channel no longer attaching when detaching

view details

Robert Mosolgo

commit sha 90941180eadaae0a88dfb98a0e2b7f68ab68de51

Merge pull request #2993 from waysact/early-disposal Fix issues around early disposal

view details

push time in 23 days

PR merged rmosolgo/graphql-ruby

Fix issues around early disposal
  1. In certain circumstances, the initial response can cause dispose to be called before the subscription has finished setting up. In this situation, the channel is never detached.
  2. Likewise, if the subscription is disposed while the Ably channel is still attaching, detaching the channel doesn't do anything.

This PR fixes both of those issues. I've also simplified cleanup based on feedback from Ably.

+56 -23

0 comment

2 changed files

jscheid

pr closed time in 23 days

Pull request review commentrmosolgo/graphql-ruby

Fix issues around early disposal

 function createAblyHandler(options: AblyHandlerOptions) {         }         // When you get an update from ably, give it to Relay         channel.subscribe("update", updateHandler)++        dispatchResult(response.body)
        // If this body contains errors, Relay will immediately clean up the subscription. 
        // To simplify the channel state, only dispatch the result _after_ the channel is set up. 
        // That way, if Relay tries to clean it up, it will get cleaned up properly.
        dispatchResult(response.body)
jscheid

comment created time in 23 days

issue closedrmosolgo/graphql-ruby

Release 1.11

I think I want to focus this on some rework of subscriptions, which may include breaking-ish changes.

  • Simplify the system:

    • [x] Remove need for extend ...SubscriptionRoot with Interpreter #2770
    • Simplify the implementation, too? It'd be great but I have no vision for how it could be improved right now
  • Support more flexible execution/delivery

    • [x] #2844
  • Implement improved subscription API

    • Turns out, this can be done with what we already have. Only the implementations need updates
    • [x] #2959 ActionCable
    • [x] Document how this works
    • [ ] Pro: Pusher, Ably and Pubnub should use this algorithm, too
  • [x] Default tests to TESTING_INTERPRETER #2860

  • [x] Migrate the schema-from-introspection-response code to build a class-based schema

    • Going into 1.10.x #2876
  • [x] Remove global tracer support #2936

Maybe some other things will come up (or be suggested here)

closed time in a month

rmosolgo

issue commentrmosolgo/graphql-ruby

Release 1.11

🚢 !

rmosolgo

comment created time in a month

push eventrmosolgo/graphql-ruby

Robert Mosolgo

commit sha cda95973abfbdd73cb26c718ae6c3c7143012a21

pro-1.14.0

view details

push time in a month

created tagrmosolgo/graphql-ruby

tagv1.11.0

Ruby implementation of GraphQL

created time in a month

push eventrmosolgo/graphql-ruby

Robert Mosolgo

commit sha 5ac332433ffed95df24dda2a7c113ba5bbd6e086

1.11.0

view details

push time in a month

PR opened rmosolgo/graphql-ruby

Pubnub subscription docs

TODO:

  • [ ] Improve pubnub link implementation
+482 -1

0 comment

9 changed files

pr created time in a month

push eventrmosolgo/graphql-ruby

Robert Mosolgo

commit sha bb70a1d2510ca06d68ef9684a3f618c0d53bc251

Hack something together that kind of works

view details

Robert Mosolgo

commit sha 917fd3b13e615491ea4618c4823fa4e0ef3f2309

Try consolidating shared resolution code

view details

Robert Mosolgo

commit sha 838a458c3f952ea5d6101f4a1c9b49649c33c569

Only add field extension when subscriptions are hooked up

view details

Robert Mosolgo

commit sha a7b7eef312e1b4b139be0216c65b261bec03ba63

Fix lint error

view details

Robert Mosolgo

commit sha 70addf087e9e8ed77091a9ff2edaff3b4b33b243

Merge branch 'master' into subscription-without-extend

view details

Robert Mosolgo

commit sha 785d5e684ac4f35a25c3847118486d8ef4abb89b

Fix test

view details

Robert Mosolgo

commit sha 77c9442ab5ea7bce1f00feae0859771f3cdb51b6

Clean up implementation and docs

view details

Robert Mosolgo

commit sha dbf6142c9b5179f4ea0049be6f3802b43f5e64d4

Fix lint error

view details

Robert Mosolgo

commit sha 800b35be0d0e959d06b85f3ed7cd7a90adff6367

Fix calling subscriber methods

view details

Robert Mosolgo

commit sha 228f26ce72f8ed05731c91b0810ca4b5ecb38627

Extract default subscription resolve

view details

Robert Mosolgo

commit sha b82bb691476dac0934882a5aff494f19dd07e0a9

Merge branch 'master' into subscription-without-extend

view details

Robert Mosolgo

commit sha 38cb7fcbf130d846291dc1da94ee9c8ae68ee673

Use send for when define_method is private

view details

Robert Mosolgo

commit sha e2711ef41b104d347b54a824a8f1efd557c97d45

Call #deliver outside #execute

view details

Robert Mosolgo

commit sha 982e8a789aca4187fa7c858da0ad86715d2aae52

Don't add pry-byebug on Ruby 2.3, where it's broken, see https://github.com/pry/pry/issues/2121

view details

Robert Mosolgo

commit sha 9a827c53cc3eeff69613601a0ed68624118da387

Merge branch '1.11-dev' into subscription-without-extend

view details

Robert Mosolgo

commit sha e44ff1affd21c8ff2ac19f810bde3ed688f0bff0

Remove global tracers support

view details

Robert Mosolgo

commit sha b8ae8345702397df51afb05de9806e13f0f7dbba

Merge branch '1.11-dev' into rework-subscriptions

view details

Robert Mosolgo

commit sha bfe347bf1f9205457700a9b723782ef874039e03

Inline resolve_field_method

view details

Robert Mosolgo

commit sha 8695e0a75ccc0940676b3715deeee69a71875534

reduce test changes

view details

Robert Mosolgo

commit sha f34d211d1e3d5a6ddfe921b7de7cf525e4a93f4a

Merge pull request #2770 from rmosolgo/subscription-without-extend Remove `extend SubscriptionRoot` from subscriptions setup

view details

push time in a month

delete branch rmosolgo/graphql-ruby

delete branch : 1.11-dev

delete time in a month

PR merged rmosolgo/graphql-ruby

Put 1.11-dev on master

Getting ready to release 1.11.0 (#2846)

+1092 -334

0 comment

45 changed files

rmosolgo

pr closed time in a month

issue commentrmosolgo/graphql-ruby

DateTime scalar change in 1.10.11 broke backwards compatibility

Thanks again for the report, I shipped a fix in 1.10.12. Please let me know if you run into more trouble!

denisahearn

comment created time in a month

create barnchrmosolgo/graphql-ruby

branch : 1.10.x

created branch time in a month

created tagrmosolgo/graphql-ruby

tagv1.10.12

Ruby implementation of GraphQL

created time in a month

push eventrmosolgo/graphql-ruby

Robert Mosolgo

commit sha e291b702128a6088c21b67b416fb86abee73078a

1.10.12

view details

push time in a month

push eventrmosolgo/graphql-ruby

Robert Mosolgo

commit sha 59ab7c14bc623c88ab3a435e178f5827f3fd9236

Improve debug codeg

view details

push time in a month

pull request commentrmosolgo/graphql-ruby

Ably robustness improvements

🚢 in 1.7.10

jscheid

comment created time in a month

push eventrmosolgo/graphql-ruby

Robert Mosolgo

commit sha bdc327f4f33c7155e7ed0281cd552475f9516289

ignore coverage for npm

view details

push time in a month

push eventrmosolgo/graphql-ruby

Robert Mosolgo

commit sha 2c4ea43f55bd1eb98c92b4e6062aa923103fdcda

js-1.7.9

view details

Robert Mosolgo

commit sha 27278f2c4c9989aa7690e32a75660fb7abcd10ff

js-1.7.10

view details

push time in a month

push eventrmosolgo/graphql-ruby

Julian Scheid

commit sha aceb55311dbc8047d3c3f9fc10f017e85257b5c6

Add Prettier to devDependencies This ensures Prettier 1.x is used for formatting.

view details

Julian Scheid

commit sha aa48ce427b8e17c6e353e36e364c40ed68ab6d54

Improve Ably error handling and unsubscription - Refactor to be async - Fix unsubscribe call (cf. https://github.com/ably/ably-js/issues/667) - Report missing X-Subscription-ID header - Report errors when entering presence - Report errors during leave or detach - Wait for leave and detach to complete before releasing channel

view details

Robert Mosolgo

commit sha 7ef6e819ea120753c9b36d4566f0b46db0cdc977

Merge pull request #2991 from waysact/ably-cleanup Ably robustness improvements

view details

push time in a month

PR merged rmosolgo/graphql-ruby

Ably robustness improvements
  • Refactor to use async/await
  • Fix unsubscribe call (cf. ably/ably-js#667)
  • Report missing X-Subscription-ID header
  • Report errors when entering or leaving presence, and when detaching
  • Wait for leave and detach to complete before releasing channel

The last item is the main reason for this PR. Currently, the ack messages that Ably sends back especially for detach won't be processed correctly because by the time they arrive, the channel has already been released and Ably can't find it in its mapping. I think this should be harmless but there is a chance this is causing problems.

The code could be a lot nicer if we could use Ably.Promise, but that would be a breaking change so I left it for another day.

+113 -53

1 comment

3 changed files

jscheid

pr closed time in a month

pull request commentrmosolgo/graphql-ruby

Ably robustness improvements

Awesome, thanks for the improvements here. (🙈 My production experience is with Pusher, which does not have as many lifecycle steps!)

jscheid

comment created time in a month

Pull request review commentrmosolgo/graphql-ruby

Only check used input arguments visibility

 def validate_non_null_input(input, ctx)             end           end -          visible_arguments_map = warden.arguments(self).reduce({}) { |m, f| m[f.name] = f; m}--          # Items in the input that are unexpected-          input.each do |name, value|-            if visible_arguments_map[name].nil?-              result.add_problem("Field is not defined on #{self.graphql_name}", [name])+          # Inject missing required arguments+          required_inputs = self.arguments.reduce({}) do |m, (argument_name, argument)|+            if !input.key?(argument_name) && argument.type.non_null? && warden.get_argument(self, argument_name)+              m[argument_name] = nil             end++            m           end -          # Items in the input that are expected, but have invalid values-          visible_arguments_map.map do |name, argument|-            argument_result = argument.type.validate_input(input[name], ctx)-            if !argument_result.valid?-              result.merge_result!(name, argument_result)+          input.to_h.merge(required_inputs).each do |argument_name, value|+            argument = warden.get_argument(self, argument_name)+            # Items in the input that are unexpected+            unless argument+              result.add_problem("Field is not defined on #{self.graphql_name}", [argument_name])+              next             end+            # Items in the input that are expected, but have invalid values+            argument_result = argument.type.validate_input(value, ctx)

generate the error instead of building missing_required_inputs

Ah, yeah, fine with me. (And I guess it must have worked this way in the past, if it wasn't triggering .visible? 🤔 )

grcooper

comment created time in a month

pull request commentrmosolgo/graphql-ruby

Fixed NoMethodError when using extras in a subscription field

💁‍♂️ ✨ https://rubygems.org/gems/graphql/versions/1.9.21 ! Thanks again for the fix.

g-gaston

comment created time in a month

created tagrmosolgo/graphql-ruby

tagv1.9.21

Ruby implementation of GraphQL

created time in a month

more