Repository navigation
Conversation
apiFetch now accepts just {queryKey} rather than a full
QueryFunctionContext, so mutations can call it directly and resolve to
the same ApiResponse ({json, headers, status}) shape the query cache
uses. queryFn usage is unchanged, since a full context still satisfies
the narrower parameter; usePinnedLogsQuery built a context literal with
extra fields and now passes only the queryKey.
The mock API client now awaits a promise body when includeAllArgs is
set. apiFetch always sets it, so specs that hold a mutation in flight
with a promise body would otherwise receive the pending promise as json.
One preprod spec passed only because of that leak and now mocks a
resolved size analysis instead.
…iFetch
Mutations in static/app views now call apiFetch({queryKey: [url, {method, data}]})
and resolve to ApiResponse, the same {json, headers, status} shape the
query cache stores. Consumers that read the response body (onSuccess,
mutateAsync callers, cache writes, explicit useMutation generics) read
.json; status and headers are now available to them as well.
Helpers with a body-typed public contract unwrap .json at the helper so
their callers stay unchanged.
This was referenced Oct 15, 2026
github-actions
Bot
added
the
Scope: Frontend
Contributor
Story previewsPreview the stories changed in this PR on the Vercel deployment:
Preview deployment: https://sentry-mw7cu25e3.sentry.dev |
Narrowing the parameter to just queryKey meant apiFetch could never use other context fields, even though a mutation could supply them itself (for example its own AbortSignal). Keep queryKey required and accept the rest optionally, so queries pass the full context as before and mutations pass what they have. usePinnedLogsQuery can again pass its full context literal.
Mutations have no query context to forward, and the other QueryFunctionContext fields (signal, client, meta) describe a running query that a mutation would have to invent. Accept just the queryKey that both callers can supply. usePinnedLogsQuery built a context literal with extra fields and now passes only the queryKey.
Match apiFetch: destructure the two context fields the function reads instead of accepting the whole query context.
…nts PR The spy targets linkProjectToRepository, which is migrated in the components PR.
This branch was successfully deployed
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
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.
Moves every
fetchMutationcall instatic/appviews outside settings toapiFetch, part of the stack that removesfetchMutation(see #127699 for the motivation). Mutations here now resolve toApiResponse({json, headers, status}), the same shape the query cache stores, so status and headers are available to them.Most of the diff is a mechanical rewrite of
fetchMutation({method, url, data, options})toapiFetch({queryKey: [url, {method, data, ...options}]}). The hand edits are the consumers of the result:onSuccesshandlers,mutateAsynccallers, cache writes, and explicituseMutationgenerics now read or declare.json. Helpers with a body-typed public contract unwrap.jsonthemselves so their callers stay unchanged.Places worth a closer look, because TypeScript would not have flagged them:
buildComparisoncomparedresponse.statusto'exists'; onApiResponsethat is the numeric HTTP status, so it now readsjson.status.useAssignIssueMutationhanded its result toGroupStorethrough ananyparameter.useCreateGroupSearchViewappended the mutation result to the starred-views cache.saveQuerycallers unwrap.jsonsosaveQueryModalkeeps its{id}contract, which non-mutation callers share.assigneeSelectorlives incomponentsbut is in this PR, because it consumesuseAssignIssueMutation.Depends on #127699. Independent of the other area PRs; the cleanup PR that deletes
fetchMutationmerges after all of them.No feature flags. No intended UI changes, so no screenshots.