#Vertex AI (google-vertex) broken in 2026.3.1

1 messages · Page 1 of 1 (latest)

coral portalBOT
#

That does smell like a 2026.3.1 regression, but that error string (“Cannot convert undefined or null to object”) is unfortunately too generic to confirm without the stack trace (it’s usually an Object.entries(...)/Object.keys(...) on something unexpected, and that can happen during init/tool-schema setup before the first API call → hence usage stays 0).

Can you paste one of these (whatever’s easiest)?

  1. Safe pasteable report (tokens redacted):
openclaw status --all
  1. Or the actual stack trace when it happens:
openclaw logs --follow

…and then trigger the failing embedded run once and copy the stack from the log.

Also helpful:

# 
openclaw --version
openclaw gateway status

Quick isolation tests (to pinpoint the layer)

  • Does it fail for both google-vertex/... and google/... (Gemini API-key provider) if you have a GEMINI_API_KEY available?
    • If both fail → likely a Google-specific init/tool-schema path regression.
    • If only vertex fails → likely ADC / Vertex auth init path regression.

Practical workaround while we triage

Since you said 2026.2.26 worked, the fastest unstick is to roll back:

openclaw update --tag 2026.2.26
openclaw gateway restart
#

If you can, file a bug (this looks real)

Once you have the stack trace, please open an issue and include:

If you drop the stack trace here, I can usually point to the exact file/line and whether there’s already a fix on main/beta.

coral portalBOT
#

The missing stack trace makes sense here: the embedded runner’s lifecycle logger only surfaces error.message (so you’ll just see Cannot convert undefined or null to object unless some other log line captures the underlying exception).

Two very actionable next steps:

1) Quick experiment: force thinking off for that session

Your failing run shows thinking=low, but models status --probe runs the embedded agent with thinkLevel: "off" and a “no tools” prompt.

So try in the same Telegram chat/session that fails:

  • send a directive-only message:
    /think:off
  • then retry the same prompt that used to crash on google-vertex/...

If that works, we’ve basically isolated this to “google-vertex + thinking != off” (regression in 2026.3.1), which is a very good bug report.

#

2) Get the real error detail via JSON logs + higher log level

Run:

openclaw config set logging.level trace
openclaw gateway restart
openclaw logs --follow --json

Then trigger the failure once and copy/paste the JSON log lines around that runId=... (often the earlier JSON line has more structured error info than the final “agent end” summary).

If it’s easier to do after the fact, grab the log file and grep by runId:

rg "2b130079-eeda-4099-ba21-51072ee0e6da" /tmp/openclaw/openclaw-$(date +%F).log | tail -n 80
#

What I’d do next

  • If /think:off fixes it: keep that as a workaround (or set agents.defaults.thinkingDefault: "off" temporarily), and file a GitHub issue with “regression 2026.3.1, google-vertex breaks unless think=off” + the JSON logs.
  • If it still fails with thinking off: then it’s more likely a tools/schema init path specific to google-vertex, and we’ll need the trace-level JSON logs to see which subsystem is throwing.

Drop the /think:off result + the --json trace snippet and we can narrow it down a lot.

#

That line isn’t the interesting one — it’s just Telegram saying “sendMessage succeeded”:

  • subsystem:"gateway/channels/telegram"
  • telegram sendMessage ok chat=... message=...

So it confirms your Telegram outbound pipeline is healthy, but it’s not related to the google-vertex crash.

What would be interesting are the JSON lines that include the embedded run + the error object, ideally with the same runId.

1) First, try a totally fresh session (important)

openclaw models status --probe uses a brand-new empty “probe-…” session every time, so it won’t hit any session-history sanitization code paths.

In the Telegram chat where it fails, send:

/new

(or /reset)

#

Then retry the same prompt on google-vertex/....

If this suddenly works, it’s very likely a corrupted/odd session history entry that only blows up on the google-vertex transcript policy path.

2) Pull the right JSON log slice (filter by runId)

Re-run with --json and then grep for the runId you see in the “embedded run start” line:

openclaw logs --json --limit 500 | rg "embedded run|runId=|google-vertex|Cannot convert"

or, once you have a specific runId:

openclaw logs --json --limit 2000 | rg "2b130079-eeda-4099-ba21-51072ee0e6da"
#

3) Check the LaunchAgent stderr log for a stack trace (often lives here)

When running as a macOS LaunchAgent, the stack trace often ends up in:

tail -n 200 ~/.openclaw/logs/gateway.err.log

(If you’re using a profile, it’ll be under ~/.openclaw-<profile>/logs/.)

If you paste the gateway.err.log snippet around the time of the failure, that’s usually enough to pinpoint the exact crashing file/line.

If you tell me whether /new changes anything, I can steer the next step (session corruption vs real 2026.3.1 regression).

coral portalBOT
#

That pastebin isn’t showing anything new yet — it’s still just the embedded runner lifecycle messages (prompt start → agent start → agent end) with only error.message, no stack trace. So nothing in there points to the root cause.

The stack is very likely going to stderr, not the JSONL file that openclaw logs --json tails.

Please grab one of these (either is fine)

A) LaunchAgent stderr (best, minimal disruption)
On the gateway Mac:

tail -n 200 ~/.openclaw/logs/gateway.err.log

(If you’re using a profile, it’ll be ~/.openclaw-<profile>/logs/gateway.err.log.)

If you can, also:

# 
rg -n "20b98762-1f8a-40ad-aa93-f7c51eb17808|Cannot convert undefined" ~/.openclaw/logs/gateway.err.log

B) Run gateway in the foreground once (guaranteed to show stack)

openclaw gateway stop
OPENCLAW_LOG_LEVEL=trace openclaw gateway --verbose

Reproduce the crash once, copy the stack, then you can Ctrl-C and openclaw gateway start again.

One more quick signal check (important)

Since your failing run shows thinking=low, can you also confirm if this workaround helps?

  1. In the Telegram chat, send:
# 
/think:off
  1. Retry a google-vertex/gemini-… message.

If that flips it from “crash” to “works”, it’s a very strong hint this is a 2026.3.1 regression in the google-vertex + thinking/tooling init path (and explains why models status --probe stays OK: probes run with think=off and “no tools”).

Once we have the stack trace, this is 100% “file a GitHub issue” material (regression + clean repro + back-compat version).

#

That paste is useful — it rules out a couple of the “usual suspects”:

  • It fails even with thinking=off (temp:slug-generator run) → so it’s not a “thinking level” incompatibility.
  • It fails with messages=0 in that temp session → so it’s not session-history corruption.
  • It fails right after [context-diag] pre-prompt … provider=google-vertex/... and immediately on embedded run agent start → this really looks like a runtime bug during agent/provider initialization (before any normal API error handling), i.e. a regression is plausible.

What we still don’t have is the stack trace (the only thing that will let someone fix it quickly). The JSON log tail doesn’t include it — it only logs error.message.

Next thing to paste (this is the money)

Right after reproducing the failure once, grab the LaunchAgent stderr log:

tail -n 200 ~/.openclaw/logs/gateway.err.log

If you’re using a profile, it’ll be:

# 
tail -n 200 ~/.openclaw-<profile>/logs/gateway.err.log

That file usually contains the full TypeError: Cannot convert undefined or null to object plus the stack (file + line).

If gateway.err.log still doesn’t show it

Run the gateway in the foreground once to force the stack into the terminal:

openclaw gateway stop
OPENCLAW_LOG_LEVEL=trace openclaw gateway --verbose

Repro once, copy stack, then restart the LaunchAgent afterwards.

What I’d do operationally