I have an App bridge app which is in need of an update that will pull metafields for a stores Products. I'm using the node version of the REST API calls, so the two endpoints being used are:
await shopify.api.rest.Product.all({
session: session,
});
to retrieve Products and:
await shopify.api.rest.Metafield.all({
session: session,
metafield: {"owner_id": "", "owner_resource": "product"},
});
to retrieve a given Product's metafields. Of course, there are rate limits in play that limit the usability of this in larger stores, but generally this has worked well in a dev version of the app. Additionally, the hook useAuthenticatedFetch is used to make the requests so that the required token is passed.
The Issue
While the above works in the dev environment, once deployed I encountered issues where some of the metafield requests would return 403 and redirect to the /auth path due to the behavior of useAuthenticatedFetch.
The possible factors as I see it are:
- Rate limits - this shouldn't be an issue as the store I'm testing is the same as the dev environment and only has about 10 Products, so with around 11 or so requests the rate limit should not be a factor.
- Scopes - the app has write_products scope so this shouldn't be a factor (and none of the requests would work if it was)
- Invalid Token - the requests all have the same token passed ('Bearer ...'), both the successful and 403's.
Is there another possible factor that would play into this that I've overlooked? As it stands, given the app will always attempt to reauthenticate with these requests I can't push forward and just accept the 403's as it ends up unusable, but while it wouldn't be ideal, if I could prevent that behavior for useAuthenticatedFetch that would also be an option.
