Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- The staff reply was posted on October 14 at 21:05 UTC. That is the confirmation time, not a published exact restoration time.
- Users reported queries and mutations on API version 2025-07. Staff did not publish a complete list of affected versions, stores or regions.
- Check the HTTP status, GraphQL errors and current business result. A failed response alone does not prove that a write never happened.
- The source provides no universal retry procedure, root cause or compensation commitment. One successful user retry does not make every mutation safe to replay.
Staff confirmed a resolution for the reported examples
In the October 14 discussion about Admin GraphQL errors, Shopify staff member KyleG-Shopify said they had investigated some of the supplied request IDs, found an issue around the same time, and that it had been resolved. They asked whether the reporters were still seeing errors. The reply was posted on October 14, 2026 at 21:05 UTC, or October 15 at 05:05 China Standard Time.
This is a clear staff response to the reports in that discussion, but it does not provide an exact restoration time. The complete thread currently has four posts, with no reporter confirmation after the staff reply. The posting time should not be treated as a fix deployment timestamp or proof that every store has recovered.
What users reported, and what remains unexplained
The initial reporter said that, from around 11:15 UTC on October 14, a custom app using Admin GraphQL API version 2025-07 intermittently received internal errors while other requests still succeeded. Listed operations included fulfillmentCreate, order, codeDiscountNodeByCode and inventoryItem, covering queries and mutations. Two other users subsequently reported similar symptoms.
The API version, approximate start time, unchanged app configuration and one later successful fulfillmentCreate retry are user reports. Staff did not publish the full impact, root cause or precise incident interval, or announce a version migration, fee change or compensation. The thread does not establish that upgrading the API version or changing a query is the fix.
Four steps to investigate lingering errors
First, collect current failures from existing logs: the exact UTC time, API version, operation name, actual HTTP status, GraphQL errors and request ID. Separate new failures from older ones so a backlog of alerts is not mistaken for errors occurring after the resolution. Do not post access tokens or complete customer data publicly.
Second, compare existing successful and failed requests from the same period, distinguish queries from mutations, and check whether the error content matches. This is troubleshooting advice to narrow the investigation; it does not mean staff have confirmed an ongoing issue for a particular operation, store or version.
Third, when a write has an uncertain outcome, use an already authorized read-only page, business record or query to inspect the current state. For example, check whether a fulfillment exists before submitting another creation request solely because the app logged an error. Match the result to the relevant order and operation time.
Fourth, send Shopify support or the staff member in the original discussion a minimal description of the operation that still fails and its supporting evidence. If the read-only check also fails, retain that result for investigation. Do not create fulfillments, change inventory or replay jobs in bulk merely to demonstrate recovery.
A successful user retry is not a general mutation replay guarantee
The thread does contain a user example of fulfillmentCreate failing and later succeeding. Staff did not publish a universal retry interval, idempotency rule or guarantee against duplicate execution. A resolution statement does not replace the duplicate-handling and reconciliation process for each write operation.
Consider a hypothetical case: an app submits a fulfillment, logs an internal error, and leaves the queue job marked failed. First inspect the order without changing it to see whether the corresponding fulfillment already exists. If it does, a failed queue status alone is not a reason to create another one. If the outcome remains unclear, preserve the job and evidence for the existing business process rather than treating this recovery report as permission to replay it.
Sources
Frequently Asked Questions
Do I need to upgrade my API version because staff said the issue was resolved?
The reply does not require an API migration. Version 2025-07 was used by the initial reporter; it is not a staff-confirmed list of affected versions. Make upgrade decisions through the app’s separate version-support and migration process rather than treating an upgrade as the verified fix for this issue.
If the reporter saw no status-page incident, does that mean the app caused the errors?
No. That was a user’s historical observation, and staff later confirmed an issue around some supplied request IDs. This article has not rechecked the current status page. An aggregate status page cannot replace investigation of the specific requests.
Should I publish complete requests, tokens and store data when asking for help?
No. Start with an operation description, UTC time, error category and relevant request ID. Do not expose access tokens or customer data publicly. If tracing needs further store context, use an appropriate private support channel and follow the team’s data-handling requirements.