shopify_app: Webhooks throwing error when deserializing admin_graphql_api_id

We started to receive webhook data including the new admin_graphql_api_id attribute today. This has a value of something akin to gid://shopify/Customer/61476333152.

The default WebhooksController is serializing the entire hash into the job request. When ActiveJob tries to deserialize the object, it’s looking at these gid’s and trying to deserialize them into ActiveRecord objects. Since these objects don’t exist on our system, we get an ActiveJob::DeserializationError.

I think I can work around this by creating a custom WebhooksController that deletes all of the admin_graphql_api_id attributes, but I’d like to see a more long-term fix in shopify_app.

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 3
  • Comments: 28 (11 by maintainers)

Most upvoted comments

I ended up filtering out all of the Global IDs from the webhook data for now.

class ApplicationJob < ActiveJob::Base

  def deserialize(job_data)
    sanitized_data = recursive_delete_gids(job_data)
    super(sanitized_data)
  end

private

  def recursive_delete_gids(hash)
    hash.each do |key, value|
      case value
      when String
        hash.delete(key) if value.start_with? 'gid://'
      when Hash
        recursive_delete_gids(value)
      when Array
        value.each do |array_value|
          recursive_delete_gids(array_value) if array_value.is_a? Hash
        end
      end
    end
  end
end

I think you could combine two strategies like this:

# config/initializers/global_id.rb

GlobalID::Locator.use :shopify do |gid|
end

Theme = Class.new
# define others as needed

Then the class will exist, but locator should just return the string back.

I’m going to close this issue for now as we’re no longer including this field for new webhooks since yesterday around ~7 PM EST (23:00 UTC).

The admin_graphql_api_id fields still exist in REST responses. They were added to help with interop/migration with our new Admin GraphQL API.

For consistency (and usefulness), they will ideally be included in webhooks again soon once we come up with a solution. This will likely involve having to update to a newer version of this gem though.

@eapache If this field will be included again in the future can we get a bit more info on the timelines and recommended handling once available? Thanks.