This repository has been archived by the owner on Apr 11, 2024. It is now read-only.
Check if a webhook is registered before calling Shopify #82
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
WHY are these changes introduced?
Our current webhook code runs into issues if we try to register a webhook that is already there, because Shopify won't accept a
webhookSubscriptionCreate
call if there is already a handler in place for that topic. It also doesn't acceptwebhookSubscriptionUpdate
calls if the callback URL hasn't changed.This PR aims to make sure the library works around those restrictions so that apps can simply request to register a webhook and trust it will be there.
WHAT is this pull request doing?
It defines a few possible execution paths for webhook registration. First of all, we check if there is already a handler for the given topic. Then:
NOTE: one unintended side effect of this change is that we're always adding new entries to the registry (as in on every successful OAuth flow). This was masked in the original code by the fact that we never succeeded in subsequent register calls because Shopify would fail. I will patch that up so that we replace the callback in the registry as well if it is there.
UPDATE: the above note was properly fixed by the PR.
Type of change