Skip to content

Comments

[7.x] New OAuth process#197

Open
nfourtythree wants to merge 16 commits into7.xfrom
feature/7.x-new-oauth-process
Open

[7.x] New OAuth process#197
nfourtythree wants to merge 16 commits into7.xfrom
feature/7.x-new-oauth-process

Conversation

@nfourtythree
Copy link
Contributor

No description provided.

@nfourtythree nfourtythree self-assigned this Feb 6, 2026
@nfourtythree nfourtythree requested a review from a team as a code owner February 6, 2026 16:54
nfourtythree and others added 10 commits February 9, 2026 16:51
The webhook has the correct object ID, but the schema (and even the underlying data) is in a different format.
This uses the API object as the source of truth, by fetching it fresh when a webhook arrives.
This is a bit of housekeeping, and a bit of soul-searching. I had a heck of a time reasoning about when and why Shopify was producing errors, so I figured it was worth expressing the variety of message structures that we may get back from the API.
- Network/connection or "client" errors, in Guzzle-land (not specific to Shopify) are caught and re-thrown with a generic message.
- API consumers (things that call `Api::query()` can basically catch a single kind of error and decide what to do
- Those queries no longer have to worry about unpacking and handling various response structures (like `userErrors`), or the root element in each response named the same as the original query or procedure.
- We now throw on any session issue before querying, rather than relying on individual consumers.
- We no longer throw on “empty” or missing `data` keys in responses (they're just returned verbatim, and it's up to the consumer to decide whether that’s “bad”)
- If you really need to perform a low-level, unopinionated query, use `Api::getGqlClient()` directly.
- Webhook setup and messaging has been improved
  - Filter webhooks by environment/URI at the API level, rather than in the controller
  - Simplified how we detect and repair "missing" webhook topic subscriptions
  - We now use a template and natural form requests and success/failure response handlers for the webhook management view
  - Moved away from deprecated `endpoint` and `callbackUrl` fields when creating and fetching webhooks, in favor of the plain `uri` field
- Bulk operation handling is no longer concerned with API response structure, errors, etc. (per above)
  - For stores that use bulk GQL *mutations*, we now look for specifically bulk *query* operations (one mutation and one query can run in parallel)
- ?!?!
…ooks

This was made easier with the introduction of GIDs (`admin_graphql_api_id`) in most/all webhooks.
Howdy, stranger! If you're reading this and would like to start a support group for Shopify developers, let me know… they have it pretty rough.
$this->getView()->registerJs($js);
}

return $this->asCpScreen()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bless. I extracted this mostly to fiddle with some connection and API stuff, knowing it was a regression in a number of ways! That might have been the first time I used a literal onclick attribute. 😭

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not entirely happy with this solution I went with if I am honest.

Would rather the "x" be an actual button to save messing around. But want to keep that consistency similar to sections and fields tables

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants