TanStack / TanStack/tanstack.com

Keep dependency updates compatible with the OpenAI continuation patch

Open
#1,212 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

source-audit
Dominant language
TypeScript
Stars
1.1k
Forks
401
Avg merge
18h 14m
Merged PRs (30d)
56

Description

Evidence

The scheduled Update TanStack Dependencies run failed before lint or build on August 30. The exact pnpm up "@tanstack/*" --latest step exits with ERR_PNPM_UNUSED_PATCH because it moves @tanstack/openai-base away from the patched 0.10.5 version.

I reproduced the same failure from current main at 6584b153. In an isolated worktree, allowing unused patches let the update finish and changed @tanstack/ai-openai from 0.22.0 to 0.22.3, with @tanstack/openai-base moving from patched 0.10.5 to unpatched 0.10.8. The focused tests/openai-responses-tool-continuation.test.ts test then failed because the second request had no previous_response_id. The current patch is still required for sequential server-tool turns with provider-side reasoning.

Exact title, body, workflow, patch-package, and keyword searches found no open issue or PR that owns this failure.

Expected impact

The weekly dependency updater is currently guaranteed to fail whenever it tries the latest TanStack AI family. It never reaches the repository lint or build steps, so unrelated TanStack dependency updates also stop. Simply setting allowUnusedPatches or deleting the patch would make the workflow advance while regressing the Builder tool-continuation contract.

Proposed direction

Keep the focused continuation test as the release gate, then choose one owner for the patched AI family:

  1. Preferred long-term direction: ship the continuation behavior upstream, update the AI packages to the first release containing it, prove the focused test passes without the local patch, and delete the patch.
  2. Until that release exists: upgrade the pinned pnpm from 11.1.0 to a version that supports update.ignoreDeps and exclude the cohesive TanStack AI package set from the scheduled bulk updater. Upgrade that set separately, carrying the patch forward only after its focused test and the full suite pass.

Alternatives and tradeoffs

  • Manually port the 321-line patch to every new openai-base release. This keeps AI packages moving, but each port needs careful review against upstream adapter changes and should not be committed straight to main by a broad scheduled update.
  • Let pnpm up ignore unused patches. This unblocks the job but silently removes required runtime behavior, and the isolated focused test already proves the regression.
  • Exclude only @tanstack/ai-openai. This may still let related direct or transitive AI packages move out of a tested version set, so excluding and reviewing the cohesive AI family is safer.

Decision needed

@tannerlinsley, should we first upgrade pnpm and hold the TanStack AI family out of the weekly bulk updater, or prioritize landing the continuation behavior upstream and keep the weekly job blocked until a release contains it?

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the scheduled pnpm up "@tanstack/*" --latest step and run tests/openai-responses-tool-continuation.test.ts against the current dependency patch. Inspect the updater workflow, pnpm configuration, and patch handling described in the issue. Done means the TanStack AI family can be updated without regressing continuation behavior, and the workflow reaches lint and build.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions, typescript
Domain
ci-cd, devops, testing-qa
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.