Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug]: pi-ai: Cannot read properties of undefined (reading 'input') when manifest/auto routes to MiniMax with model.input or message.usage missing [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#75862•Fetched 2026-05-02 05:28:48
View on GitHub
Comments
1
Participants
2
Timeline
4
Reactions
2
Author
timchow1228timchow1228
Participants
clawsweeper[bot]clawsweeper[bot]timchow1228timchow1228
Timeline (top)
labeled ×2closed ×1commented ×1

Upgrading to 2026.4.x causes a crash (TypeError) in pi-ai when routing to MiniMax via manifest/auto due to missing defensive checks on 'message.usage' and 'model.input'.

Root Cause

Root Cause: In transform-messages.js and openai-responses-shared.js, there is a lack of null-checks for provider-specific responses.

RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Upgrading to 2026.4.x causes a crash (TypeError) in pi-ai when routing to MiniMax via manifest/auto due to missing defensive checks on 'message.usage' and 'model.input'.

Steps to reproduce

  1. Use OpenClaw version >= 2026.4.x.
  2. Configure an agent with manifest/auto routing that resolves to MiniMax.
  3. Trigger a cron job or an isolated agent session.
  4. Observe the process crash when MiniMax returns a response without the expected usage or input fields.

Expected behavior

The system should handle LLM responses gracefully even if optional fields like usage are missing, using optional chaining or defensive checks.

Actual behavior

The application crashes with TypeError: Cannot read properties of undefined (reading 'input') or similar, specifically at message.usage.input_tokens and model.input.includes("image").

OpenClaw version

2026.4.26

Operating system

Ubuntu 22.04.5 LTS

Install method

docker

Model

manifest/auto (MiniMax)

Provider / routing chain

MiniMax

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

Root Cause: In transform-messages.js and openai-responses-shared.js, there is a lack of null-checks for provider-specific responses.

Suggested Fix: // Use optional chaining and array checks message.usage?.input_tokens; Array.isArray(model.input) && model.input.includes("image");

extent analysis

TL;DR

Update the transform-messages.js and openai-responses-shared.js files to include defensive checks for message.usage and model.input using optional chaining and array checks.

Guidance

  • Verify the absence of null checks in transform-messages.js and openai-responses-shared.js for provider-specific responses.
  • Apply optional chaining for message.usage as message.usage?.input_tokens to prevent TypeError.
  • Add array checks for model.input as Array.isArray(model.input) && model.input.includes("image") to ensure safe access.
  • Review the code for similar instances where defensive checks might be missing.

Example

// Before
const inputTokens = message.usage.input_tokens;

// After
const inputTokens = message.usage?.input_tokens;

Notes

This fix assumes that the missing fields are optional and should not cause the application to crash. Additional logging or error handling might be necessary to handle cases where the fields are missing.

Recommendation

Apply workaround by adding defensive checks to transform-messages.js and openai-responses-shared.js to prevent the application from crashing due to missing fields in provider-specific responses.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

The system should handle LLM responses gracefully even if optional fields like usage are missing, using optional chaining or defensive checks.

#LLM response#runtime error#dependency conflict#environment setup#docker error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING