decide() drops billed usage when a call fails after the provider responded
Los mantenedores suelen responder en 1 día
Evaluación
Este issue todavía no se ha evaluado.
Descripción
TanStack AI version
@tanstack/ai 0.68.0, @tanstack/ai-openai 0.29.1 (current main)
Framework/Library version
None. decide() runs on the server, Node.js v24.14.1.
Describe the bug and the steps to reproduce it
decide() only reports token usage on the success path. When the provider answers and bills the call, but decide() then throws, onUsage never runs and no evaluate:usage event fires. The tokens are billed but never metered. We use decide() in a planner and meter tokens through onUsage, so every one of these failures under-reports our spend.
Two concrete cases on main.
Case 1: the answers cannot be mapped. Shipped adapters pass provider answers through unchecked (for example packages/ai-typesafe/src/adapters/evaluate.ts returns json.answers as is). If an answer is missing, or has the wrong type for its question, mapAnswers throws inside decide() after adapter.evaluate() resolved. result.usage is in scope at that point and is dropped. onError runs, onUsage does not.
Case 2: OpenAI refuses a question. packages/ai-openai/src/adapters/evaluate.ts throws a plain Error('OpenAI declined to answer question "<name>"') from inside the decision.answers.map(...). The response is already in hand, so three things are lost at once: the usage from decision.usage, every other answer in the response, and any typed way to detect a refusal. The caller gets a plain Error with no code, and the adapter log entry has code: undefined. I have no deterministic repro for this one. It needs a real refusal from gpt-6-luna. The code path is visible in the file.
Maintainers already treat lost usage as a bug on the chat side: #1609 (merged) keeps Anthropic usage when a stream stops at max_tokens, and #1735 (open) reports Anthropic usage lost on a stream failure. decide() has the same hole.
Steps to reproduce case 1 on clean main:
- Save the test below as
packages/ai/tests/decide-usage-repro.test.ts. - Run
pnpm nx run @tanstack/ai:test:lib --skip-nx-cache -- tests/decide-usage-repro.test.ts. - The test fails with
AssertionError: expected [] to deeply equal [ { promptTokens: 40, …(2) } ].decide()threw as expected, buthookUsageandeventUsageare both empty.
import { expect, it } from 'vitest'
import { aiEventClient } from '@tanstack/ai-event-client'
import { boolean, decide } from '../src/index'
import type { TokenUsage } from '../src/types'
it('decide() reports billed usage when the answers cannot be mapped', async () => {
const usage = { promptTokens: 40, completionTokens: 5, totalTokens: 45 }
const hookUsage: Array<TokenUsage> = []
const eventUsage: Array<TokenUsage> = []
const off = aiEventClient.on('evaluate:usage', (e) => eventUsage.push(e.payload.usage), { withEventTarget: true })
const call = decide({
adapter: {
kind: 'evaluate', name: 'repro', model: 'repro-model', '~types': { providerOptions: {} },
// The provider answered and billed tokens, but the answer has the wrong type.
evaluate: async () => ({
model: 'repro-model', usage,
answers: { refund: { type: 'choice', choice: 'x', probabilities: { x: 1 }, confidence: 1 } },
}),
},
state: 'Please refund the extra payment.',
questions: { refund: boolean({ instructions: 'Is this a refund request?' }) },
middleware: [{ onUsage: (_ctx, u) => void hookUsage.push(u) }],
debug: false,
})
await expect(call).rejects.toThrow('expected noul answer for "refund"')
off()
expect(hookUsage).toEqual([usage])
expect(eventUsage).toEqual([usage])
})
Expected: onUsage and evaluate:usage get the usage the provider reported, then onError runs and decide() rethrows. onFinish stays off for a failed call.
Actual: nothing reports the usage.
Your Minimal, Reproducible Example - (Sandbox Highly Recommended)
Inline above. It is a Vitest test against this repo, no sandbox needed.
Screenshots or Videos (Optional)
No response
Do you intend to try to help solve this bug with your own PR?
Yes, I am also opening a PR that solves the problem along side this issue
Terms & Code of Conduct
- I agree to follow this project's Code of Conduct
- I understand that if my bug cannot be reliable reproduced in a debuggable environment, it will probably not be fixed and this issue may even be closed.
- Lenguaje dominante
- TypeScript
- Estrellas
- 3.2k
- Forks
- 361
- Merge medio
- 1 d 8 h
- PR fusionados (30 d)
- 266
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de TanStack/ai
-
Discriminate status-dependent record and option types (RunRecord, SessionIndexEntry, InputState, durable-only options)Posiblemente ocupada @jherr la tomó hace 1 día. Abiertoenhancement waiting-on: maintainer
TanStack/ai#1799 · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
ai-harness: an input with no principal runs with the owner session's principalPosiblemente ocupada @tombeckenham la tomó hace 1 día. Abiertowaiting-on: maintainer
TanStack/ai#1797 · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
ai-harness: a forwarded command completes with no result, also when the owner rejects itPosiblemente ocupada @tombeckenham la tomó hace 1 día. Abiertowaiting-on: maintainer
TanStack/ai#1796 · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
ai-harness: recovery runs a turn without the user message when the turn never startedPosiblemente ocupada @tombeckenham la tomó hace 1 día. Abiertowaiting-on: maintainer
TanStack/ai#1795 · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
ai-mcp: modern tool calls omit x-mcp-header parameter headers in 0.9.0Posiblemente ocupada @tombeckenham la tomó hace 1 día. Abiertowaiting-on: maintainer
Dificultad 4/5 3-5 días Aptitud para principiantes 32/100
TanStack/ai#1794 · 1 asignado ·
Los mantenedores suelen responder en 1 día
Todos los issues de TanStack/ai
Issues similares
-
`cf complete zsh >> .zshrc` fails on vanilla zshQuizá libre de nuevo Un pull request para esta issue se cerró sin fusionarse. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
cloudflare/cf#340 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
Rename Madson cameraAbierto
Dificultad 2/5 Menos de una hora Aptitud para principiantes 75/100
StoDevX/AAO-React-Native#8785 ·
Los mantenedores suelen responder en 1 día
-
Broken links in the docsAbierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 75/100
-
bnv-manager-v2: accept_invite creates the Mailcow domain admin before the commitPosiblemente ocupada @myOmikron la tomó hoy. Abiertobug ready-for-agent
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100