Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[M3 Bug] Tool calling: array arguments always emitted as {"item": [...]} (100% reproducible, trigger independent of field name) + numeric arguments serialized as strings

Aperta
  • Qualcosa non va?
#37 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
json
Ambito
ai

Direzione di ricerca

Start by comparing the reported tool-call arguments with the JSON schemas in the issue, especially the array fields and numeric fields. The report does not identify repository files, tests, or an implementation entry point, so first locate where tool-call arguments are generated or validated. Done means reproducing the wrapped arrays and stringified numbers and confirming the emitted arguments match the declared schema types.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

Reporting a second, always-reproducible variant of the item-wrapping bug in #29, plus a related number-serialization issue. Unlike #29 (15-35% intermittent, trigger narrowed to a property named item_ids together with a prompt that avoids the word "item"), this variant is 100% reproducible and fires on array fields whose names have nothing to do with item.

Two symptoms, both in the model's own tool-call arguments, before any client-side validation:

  1. Array arguments are emitted as {"item": [...]} instead of a JSON array.
  2. Numeric arguments are emitted as JSON strings ("maxCharacters": "6000").

Reproduction: 100% of calls, across three tools

Client: OpenAI-compatible chat-completions endpoint, agent harness. No sampling parameters set.

Tool / argument Model Shape emitted Result
suggestions (array of objects) MiniMax-M3.1-Flash {"item": [...]} schema validation rejects the call
suggestions (array of objects) DeepSeek (same harness, same schema) [...] accepted
reviewed (array of strings) MiniMax-M3.1-Flash {"item": [...]} schema validation rejects the call
reviewed (array of strings) DeepSeek (same harness, same schema) [...] accepted
urls (array of strings) MiniMax-M3.1-Flash {"item": [...]} schema validation rejects the call
urls (array of strings) DeepSeek (same harness, same schema) [...] accepted

Same tool, same schema, same harness, same argument names - only the model differs. Over 1,500 MiniMax tool calls in our logs, every wrapped array used the key item; no other key ever appeared.

The trigger is not an item* property name

#29's 2026-07-28 update narrows the trigger to a property named item_ids (or similar item*) combined with a prompt that never uses the word "item", and reports that "realistic schemas with no item* property have been clean in everything I have run since - 26/26 calls on one real workload, and 56/56 on a larger schema".

That does not hold for the schemas below. None of the array fields is named item*:

{
  "type": "object",
  "properties": {
    "suggestions": { "type": "array", "items": { "type": "object", "properties": { "title": { "type": "string" } } } },
    "reviewed":    { "type": "array", "items": { "type": "string" } }
  },
  "required": ["suggestions"]
}

and:

{
  "type": "object",
  "properties": {
    "urls": { "type": "array", "items": { "type": "string" } },
    "maxCharacters": { "type": "number" }
  },
  "required": ["urls"]
}

For these, the item wrapping occurs on every single call (22/22 and 5/5 in our logs), and the field name is irrelevant. A separate card-rendering schema declaring "sections": {"type": "array"} explicitly - i.e. the shape is unambiguous - also wraps on every call.

One hypothesis worth considering: items is the JSON Schema keyword for array elements, and the model may be conflating that keyword with an output key whenever the schema uses items for element typing - which is to say, in essentially every array schema - regardless of the property's own name.

Number arguments are serialized as strings

A separate symptom in the same tool calls: numeric arguments arrive as JSON strings, so a number schema rejects them.

{ "server": "exa", "tool": "exa_web_fetch_exa",
  "arguments": { "maxCharacters": "6000", "urls": { "item": ["https://example.com/a", "https://example.com/b"] } } }

The schema declares maxCharacters as number; the client-side validator reports maxCharacters 需要 number，收到 string. A numResults: 2 argument is likewise emitted as "2".

The same harness, same tool, same argument, with DeepSeek emits "maxCharacters": 6000 as a native number and succeeds.

Why this matters beyond cosmetics

The malformed arguments are syntactically valid JSON, so nothing raises on parse. The failure surfaces only when the consumer validates against the schema, and by then the model's output has already been discarded and the call has to be retried. In an agent loop that means the tool never runs, the model sees a validation error instead of a result, and the surrounding task can fail or silently lose data. In our case one of the affected tools is the heartbeat's own log-recording call, so the patrol record was simply missing for those runs.

Questions

  • Is this the same root cause as #29, and does the fix for #29 also cover the always-reproducible variant?
  • Is there a supported strict / constrained-decoding mode for tool calls that would enforce the declared JSON types?
  • Is the number-to-string serialization related to the same mechanism, or separate?

Notes on version

Observed with MiniMax-M3.1-Flash through an OpenAI-compatible gateway. Happy to supply raw request/response pairs and the exact schemas if useful.

Lingua principale
Nessun dato sulla lingua
Stelle
493
Fork
60
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di MiniMax-AI/MiniMax-M3

Tutte le issue di MiniMax-AI/MiniMax-M3

Issue simili

Altre issue su AI Infra & Agents

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.