Automatic rate limit restoration w/ admin API calls #6688
+141
−26
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Dec 5, 2025
Contributor
Author
This stack of pull requests is managed by Graphite. Learn more about stacking. |
Contributor
Coverage report
Show new covered files 🐣
Show files with reduced coverage 🔻
Test suite run success3452 tests passing in 1397 suites. Report generated by 🧪jest coverage report action from 68d8802 |
Contributor
|
We detected some changes at Caution DO NOT create changesets for features which you do not wish to be included in the public changelog of the next CLI release. |
shauns
force-pushed
the
shauns/12-05-automatic_rate_limit_restoration_w__admin_api_calls
branch
from
80c8dcb to
68d8802
Compare
Contributor
Differences in type declarationsWe detected differences in the type declarations generated by Typescript for this branch compared to the baseline ('main' branch). Please, review them to ensure they are backward-compatible. Here are some important things to keep in mind:
New type declarationsWe found no new type declarations in this PR Existing type declarationspackages/cli-kit/dist/public/node/http.d.ts@@ -18,7 +18,7 @@ type AutomaticCancellationBehaviour = {
} | {
useAbortSignal: AbortSignal | (() => AbortSignal);
};
-type RequestBehaviour = NetworkRetryBehaviour & AutomaticCancellationBehaviour;
+export type RequestBehaviour = NetworkRetryBehaviour & AutomaticCancellationBehaviour;
export type RequestModeInput = PresetFetchBehaviour | RequestBehaviour;
/**
* Specify the behaviour of a network request.
packages/cli-kit/dist/public/node/api/graphql.d.ts@@ -47,6 +47,7 @@ export type GraphQLRequestDocOptions<TResult, TVariables> = GraphQLRequestBaseOp
}>>;
variables?: TVariables;
unauthorizedHandler?: UnauthorizedHandler;
+ autoRateLimitRestore?: boolean;
};
export interface GraphQLResponseOptions<T> {
handleErrors?: boolean;
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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?
Add optional support for automatic recovery of rate limit consumed in Admin API calls. If a call consumes 10 units (from
extensions.cost.actualQueryCost), and the recovery rate per second is 1000 units (fromextensions.cost.restoreRate), then we should wait 0.01s after making our API call to ensure the same amount of tokens we've consumed have had the chance to recover.This means we can have code that hits the Admin API in succession -- such as Metafield import, where there are many queries to make -- without being a bad citizen or hitting a rate limit.
From a callers perspective its as if the API call took very very slightly longer.
WHAT is this pull request doing?
After making a GraphQL call, if the relevant option is enabled, inspect the
extensions.costpart of the raw GraphQL response, check for unit usage/recovery rate, and sleep the requisite amount of time. The time is dependent on query complexity, but it's often no more than double digit milliseconds.Sleep information is included in the debug output. Time spent sleeping is counted under network usage time for analytics purposes.
How to test your changes?
There's good test coverage, and an upstack PR makes direct use of this in a CLI command
Measuring impact
How do we know this change was effective? Please choose one:
Checklist