跳到正文
DEV Community· Sushil·· 5 小時前AI 評分65

AI SDK 7.0.160 開始驗證 dataPartSchemas,載入狀態可能觸發錯誤

AI SDK 7.0.160 Started Enforcing dataPartSchemas. Your Loading States Might Now Throw

AI 導讀

AI SDK 7.0.160 起,useChat 和 Chat 會驗證 dataPartSchemas,原先未執行的檢查可能令不符合 schema 的串流資料觸發 TypeValidationError,並使聊天進入 error 狀態。

正文

If you pass dataPartSchemas to useChat and bump ai to 7.0.160 or later, a chat that worked yesterday can end up in status: 'error' with a TypeValidationError. You didn't change anything. Your schemas just started running.

What changed

useChat and Chat accept dataPartSchemas, keyed by the bare part name (weather for a data-weather part). The stream processor looked the schema up by the full chunk type (data-weather), so the lookup always missed and streamed data parts were never validated. That's issue #24241, fixed in PR #24298 and shipped in ai 7.0.160: "Invalid data parts now raise a TypeValidationError."

So a patch release turned on a check that was configured but never ran.

What I ran

I didn't want to guess at the edge cases, so I drove the Chat class from @ai-sdk/react with a fake transport that replays fixed UI message chunks. No model, no network. useChat runs on that same class (its chat option even takes an existing Chat instance), so the stream handling is the same code path. I ran the same script against ai 7.0.159 with @ai-sdk/react 4.0.163, ai 7.0.162 with @ai-sdk/react 4.0.166, and ai 6.0.322 with @ai-sdk/react 3.0.325, all with zod 4.6.7 on Node 20.19.2.

Stream 7.0.159 7.0.162
Valid data-weather part ready ready
city: 42, then some text ready, bad data kept in parts, text arrives error, no assistant message at all
Loading update without weather, then the final value ready error, earlier text kept, final value lost
Transient part that fails the schema ready, onData called error, onData not called
data-notice part with no schema ready ready

On 6.0.322 every row matched the 7.0.159 column: bad data went through without an error.

The one that'll bite: progressive updates

The streaming data docs use a progressive pattern: write { city, status: 'loading' } first, then write to the same id again with the real value. The docs type weather as optional (weather?: string), which fits that pattern. But if your zod schema was written for the finished shape, the loading chunk fails now. Here's the excerpt from my test script (start and end are the start/finish chunks, text() writes one text part, and run() sends a message through Chat with these chunks):

const strictSchemas = {
  weather: z.object({
    city: z.string(),
    weather: z.string(),
    status: z.enum(['loading', 'success']),
  }),
};

// Case 3: a loading update, then the final value under the same id
await run('3 loading update without weather, then final', [...start,
  ...text('t0', 'Checking...'),
  { type: 'data-weather', id: 'w1', data: { city: 'Berlin', status: 'loading' } },
  { type: 'data-weather', id: 'w1', data: { city: 'Berlin', weather: 'sunny', status: 'success' } }, ...end]);

On 7.0.162 this ended with Type validation failed for message.parts[2].data (data-weather, id: "w1"). The "Checking..." text that streamed before it stayed in the message, the final value never arrived, and chat.status was error.

Every chunk is checked, not just the last one per id. Transient parts too, even though they never land in message.parts.

The fix

Make the schema describe every state the server actually sends. A discriminated union keeps the final shape strict:

const unionSchemas = {
  weather: z.discriminatedUnion('status', [
    z.object({ status: z.literal('loading'), city: z.string() }),
    z.object({ status: z.literal('success'), city: z.string(), weather: z.string() }),
  ]),
};

With this schema the same stream finished with status: ready on both versions, and the part ended up as { city: 'Berlin', weather: 'sunny', status: 'success' }.

Before you upgrade, I'd do three things:

  1. Search the client for dataPartSchemas.
  2. For each data-* type in there, check every writer.write() on the server against its schema, including loading, progress and transient writes.
  3. Make sure the UI shows error from useChat. In my runs a failed part stopped the whole response, so a silent failure here looks like a chat that just stops.

Data parts with no schema aren't checked at all, so a schema-less type won't start failing.

I'd rather have the error than let city: 42 slip into message.parts without a word, which is what 7.0.159 did. Have you hit this one after updating, or were your schemas already matching what the server sends?

References

來源:DEV Community · dev.to