DEV Community: xn

Gemini 3.8 Flash vs 3.7 Flash: Same Price, Different Agent Cost?

xn — Thu, 03 Sep 2026 05:46:19 +0000

A production-focused update based on a real project: Gemini 3.8 Flash vs 3.7 Flash: compare pricing, 1M context, thinking levels, coding/agent changes, migration steps, and why eq…

The most important Gemini 3.8 Flash vs 3.7 Flash distinction is not the API rate card. The two models currently have the same token prices, but that does not mean they will cost the same to finish the same job. Google released Gemini 3.8 Flash on September 2, 2026 and kept the same introductory input/output rates as 3.7 Flash. At the same time, Google explicitly says 3.8 “works harder” on complex tasks: it can take more reasoning steps, call tools iteratively, and verify its work, which can increase token use on longer agentic runs.

If you are searching for Gemini 3.8 Flash vs 3.7 Flash, 3.8 pricing, the API model ID, whether coding agents should upgrade, or why the same token price can still produce a higher bill, the practical answer is: 3.8 is a stronger migration candidate for long-horizon software engineering and multi-tool agents; stable, latency-sensitive and efficiency-first workloads do not need to leave 3.7 just because a newer model exists.

Evidence boundary: this page is an official-evidence migration and model-selection guide, not an XBSTACK API A/B benchmark. We have not yet run 3.8 and 3.7 through the same repository tasks, prompts, thinking levels and tool permissions in a repeatable test matrix, so Google benchmark results remain Google results rather than “our tests.”

Gemini 3.8 Flash vs 3.7 Flash at a glance

Item	Gemini 3.8 Flash	Gemini 3.7 Flash
Model ID	`gemini-3.8-flash`	`gemini-3.7-flash`
Release status	GA	GA
Context window	1M tokens	1M tokens
Max output	64K tokens	64K tokens
Thinking levels	low / medium / high	low / medium / high
Default thinking	medium	medium
Input price through 2026-12-31	$0.75 / 1M tokens	$0.75 / 1M tokens
Output price through 2026-12-31	$3.75 / 1M tokens	$3.75 / 1M tokens
Primary positioning	Long-horizon software engineering, autonomous agents, complex enterprise workflows	Efficient coding, agents and reliable multi-step execution
Still supported by Google	Current flagship Flash	Yes, fully supported

Google’s current pricing documentation also gives a date for the next step: the introductory rates run through December 31, 2026. Starting January 1, 2027, the listed standard rates become $1.50/M input and $7.50/M output tokens.

That means the obvious specification table is not where the real decision lives. The bigger difference is how the model spends reasoning and tool-use budget inside a task.

Official source: Gemini API — What’s new in Gemini 3.8 Flash

Why can Gemini 3.8 cost more per task if the token rate is identical?

Google is unusually explicit about this trade-off. On difficult tasks, 3.8 may take smaller reasoning steps, call tools multiple times and verify intermediate work. At higher effort levels, this can increase token consumption.

So a production model-cost calculation should not stop at:

input rate + output rate

A better unit is:

task completion cost = input tokens + output/thinking tokens + extra tool-call turns + retries/failures + human correction time

If 3.8 consumes more tokens but significantly reduces failed loops, rework and manual correction, it may still reduce the cost of completing the job. If the job is simple and already succeeds in one pass, extra reasoning can simply become extra spend.

That is why Google presents both paths as valid:

use 3.8 with medium/high effort for hard workflows;
lower the effort for efficiency-sensitive work, or keep using 3.7 Flash.

For XBSTACK, that is the key reason we will not translate “same price” into “same task cost” without a controlled workload test.

What actually improved for coding and agents?

Google positions Gemini 3.8 Flash around long-horizon software engineering and autonomous agents, not generic chat quality.

The launch material points to four practical areas:

Long-running software engineering: multi-file and multi-stage tasks that require continued verification;
Agentic workflows: multi-step planning and tool orchestration with fewer failed loops;
Complex professional workflows: analytical and reporting tasks that need multiple checks;
Iterative tool verification: more willingness to use tool feedback to refine a result instead of stopping after one generation.

Google’s published DeepSWE and Vals Finance Agent results support that direction, but they remain vendor evaluations. Whether 3.8 is better in your repository still depends on tool definitions, codebase size, run length, recovery design and budget constraints.

How do you call Gemini 3.8 Flash in the API?

The model ID is straightforward:

gemini-3.8-flash

Google currently labels the model GA and provides examples through the Gemini Interactions API.

The migration work is more important than the model string. Google’s 3.8 migration checklist calls out several configuration changes:

remove deprecated temperature, top_p and top_k generation parameters;
replace thinking_budget with the string thinking_level enum;
do not use minimal with 3.8 Flash;
remove unsupported candidate_count;
standardize multi-turn conversations on server-side previous_interaction_id;
audit function-calling payloads, including call_id and name where required;
do not assume older Gemini 2.x or early 3.x sampling/prompt behavior will migrate unchanged.

If a project only replaces gemini-3.7-flash with gemini-3.8-flash and ignores those constraints, a migration error can easily be mistaken for a model-quality regression.

Which thinking level should you use?

Google’s current guidance maps cleanly to a production routing strategy:

Workload	Reasonable starting point	Why
Real-time chat, short summaries, light data work	low	Prioritize latency and token efficiency
Code analysis, general agents, multi-step business flows	medium	Default balance of quality and cost
Hard reasoning, difficult coding, complex multi-tool workflows	high	Maximize reasoning and tool orchestration

Do not treat high as a universal production default. One common way to waste agent budget is to run every task at maximum reasoning intensity.

A better policy is task routing: simple jobs on low, complex jobs on medium, and only truly hard paths on high.

Should existing Gemini 3.7 Flash workloads upgrade now?

Stronger candidates for immediate 3.8 evaluation

coding agents that routinely edit multiple files;
workflows that run across many steps and repeatedly execute tests or builds;
agents that call multiple tools and plan from their results;
workloads where 3.7’s main problem is failed loops or human takeover rather than single-call latency;
systems that already record token use, success rate, retries and correction time per task.

Reasons to stay on 3.7 for now

the workload is stable and cost/latency are already predictable;
tasks are short and tool use is light;
you do not yet have a repeatable regression suite to measure migration impact;
per-task token budget matters more than hard-task completion rate.

Google explicitly says 3.7 Flash remains fully supported, so there is no official “3.8 shipped, therefore migrate now” requirement.

Is Gemini 3.8 Flash Cyber just a stronger 3.8 Flash?

Not for normal API selection.

Gemini 3.8 Flash Cyber is intended for high-permission defensive cybersecurity work and is distributed through the Fairwind Program to trusted governments, critical-infrastructure operators, software maintainers and other approved defenders. It has a different safety/access boundary and should not be treated as the normal “Pro” tier of Gemini 3.8 Flash.

For ordinary coding agents and enterprise workflows, the useful comparison is 3.8 Flash vs 3.7 Flash, not “can I get Cyber?”

Gemini 3.8 Flash vs 3.7 Flash: which one should you choose?

Situation	More reasonable choice
New complex coding agent	Evaluate 3.8 Flash first
Existing agent has multi-step failure loops	Run a controlled 3.8-vs-3.7 regression suite
Cost-sensitive short tasks	Keep 3.7 or test 3.8 at low effort
“Same price means automatic upgrade”	Compare per-task tokens and completion cost first
Need high-permission cyber defense	Review 3.8 Flash Cyber/Fairwind eligibility separately
No regression suite exists	Build the task set before migrating

If you are also comparing the newest Claude coding/agent releases, see Claude Fable 5.1 vs Mythos 5.1: pricing, access, coding and agent trade-offs. Read together, the releases point to the same broader trend: model competition is moving from single-turn chat scores toward long-running coding, agent tool use and total cost to complete a real task.

To turn that model choice into production routing, cost controls, approvals and regression evaluation, continue with Production Governance for AI Agents. For repository, issue, log and engineering workflows, use AI Developer Engineering Agents as the next implementation layer.

What would a real XBSTACK benchmark need to test?

A useful test should not repeat a vendor leaderboard. It should lock a set of real tasks:

the same multi-file code change;
the same tool-calling agent workflow;
the same long-document or data-analysis job;
identical thinking levels and tool permissions;
success rate, manual edits, input/output tokens, tool-call count and final cost;
at least one preserved failure case instead of only best-case outputs.

Only after that matrix is repeatable should “3.8 is more reliable” or “3.8 is cheaper per completed task” become an XBSTACK hands-on conclusion.

FAQ

Is Gemini 3.8 Flash available through the API now?

Yes. Google’s developer guide lists gemini-3.8-flash as GA and provides Interactions API examples.

Is Gemini 3.8 Flash more expensive than 3.7 Flash?

Not on the current per-token rate card. Both are $0.75/M input and $3.75/M output through December 31, 2026. But 3.8 can use more reasoning/tool-call tokens on difficult tasks, so the total bill for one completed task can differ.

What is the Gemini 3.8 Flash context window?

Google currently lists a 1M-token context window and a 64K-token maximum output.

Does Gemini 3.8 Flash support minimal thinking?

No. The current supported levels are low, medium and high. Google says minimal will return an error.

Is Gemini 3.7 Flash being discontinued?

Google explicitly says 3.7 Flash remains fully supported and presents it as an option for efficiency-first workloads.

Should I switch production traffic directly to 3.8?

Not based on the version number alone. Run your real regression tasks first and compare success rate, token use, tool calls, corrections and latency before changing the default route.

Official sources

Canonical article on XBSTACK：https://www.xbstack.com/en/ai/gemini-3-8-flash-vs-3-7-flash/?utm_source=devto&utm_medium=referral&utm_campaign=article_distribution&utm_content=gemini-3-8-flash-vs-3-7-flash&ref=devto

标签：#AI #SoftwareEngineering #DeveloperTools #Gemini #Google AI

Claude Fable 5.1 vs Mythos 5.1: Same Model, Different Access Boundary

xn — Wed, 02 Sep 2026 07:51:50 +0000

Claude Fable 5.1 and Claude Mythos 5.1 look like a normal model split at first glance. They are not.

The important line in Anthropic’s launch post is that both names refer to the same underlying model. The difference is the safeguard configuration and who is allowed to use each access path.

The practical decision

For most developers, the decision is simple: evaluate Claude Fable 5.1 first. Fable is the generally available version across Claude products, the API, Claude Code, and major cloud platforms.

Mythos is not a higher tier that a regular developer unlocks by paying more. It is restricted to vetted cybersecurity and life-sciences organizations through trusted access programs.

Pricing is only part of the story

The standard Fable 5.1 API price remains $10 per million input tokens and $50 per million output tokens. The more interesting change is cache read pricing: $0.25 per million tokens.

That matters for agent workloads because agents often carry the same repository context, tool descriptions, project policies, and task state through multiple steps. If the workflow can reuse cached context, the effective cost profile changes.

Do not over-read vendor benchmarks

Terminal-Bench and CursorBench are useful signals, but they are not a substitute for running the model against your own repository, prompts, tools, and acceptance criteria. A coding-agent workflow can fail because of tool permissions, state recovery, cache misses, or data-retention constraints even when the base model is strong.

My working rule is: treat Fable 5.1 as a candidate for the normal production evaluation matrix; treat Mythos 5.1 as a specialized access program, not a default upgrade path.

Canonical article and full comparison: https://www.xbstack.com/en/ai/claude-fable-5-1-vs-mythos-5-1/?utm_source=devto&utm_medium=referral&utm_campaign=claude_fable_mythos_51&utm_content=original&ref=devto

MCP StreamableHTTPClientTransport POST Stays Pending After SSE Disconnect: Issue #2739 Re…

xn — Tue, 01 Sep 2026 03:31:52 +0000

A production-focused update based on a real project: A v1 MCP StreamableHTTPClientTransport POST can remain pending until request timeout after request-scoped SSE error/EOF. XBSTA…

If you use the v1 @modelcontextprotocol/sdk StreamableHTTPClientTransport and see a strange failure pattern—the POST has already received text/event-stream, the request-scoped SSE has died, client.onerror may already have fired, but client.ping() or another request still sits pending until the normal request timeout—do not automatically classify it as a slow server or a generic network timeout.

On September 1, 2026, I independently reran the lifecycle boundary described in upstream Issue #2739 on Node.js 22.18.0. @modelcontextprotocol/sdk 1.29.0 and the current npm release, 1.30.0, both reproduce it. In the erroring-SSE case, the transport reports the failure within roughly 3–4 ms, yet the JSON-RPC request rejects only when the 300 ms test timeout expires. With clean EOF, there is no client.onerror in the reproduction and the request still waits for timeout. An application/json control resolves in about 1 ms.

This article stays narrow: why a request-scoped SSE leg can become incapable of delivering its JSON-RPC result while the corresponding v1 request remains pending, and what you can safely do until the SDK lifecycle is fixed.

First, verify that your failure matches this boundary

The closer your case is to these conditions, the more relevant #2739 becomes:

You are on the v1 @modelcontextprotocol/sdk StreamableHTTPClientTransport.
The POST response uses Content-Type: text/event-stream.
The server accepted the JSON-RPC request.
The request-scoped SSE body errors or reaches EOF before the matching JSON-RPC result or error arrives.
In the error case, client.onerror may fire quickly while the request Promise remains unsettled.
The final caller-visible failure is just MCP error -32001: Request timed out.

This is not the same diagnostic path as initialization failure, HTTP 401/403, -32700 Parse error, reverse-proxy buffering, a server that never accepted the POST, or a stream lost only after explicit cancellation. Upstream #2739 explicitly distinguishes its no-cancellation reproduction from related lifecycle issue #2691.

Reproduction design: three POST response modes, no real server required

I wanted to remove OAuth, reverse proxies, external networking, model APIs and tool logic from the experiment. Instead of running a real remote MCP server, the test injects a custom fetch into StreamableHTTPClientTransport. Initialization returns normal JSON; only the ping response changes:

A. erroring SSE
POST ping -> text/event-stream -> controller.error()

B. clean EOF
POST ping -> text/event-stream -> controller.close()

C. JSON control
POST ping -> application/json -> matching JSON-RPC result

The request timeout is fixed at 300 ms. That isolates one question: if the transport knows within a few milliseconds that the request-scoped SSE leg can no longer deliver a result, does the request Promise settle immediately?

The key test fragment is small:

if (message.method === 'ping') {
  const body = new ReadableStream({
    start(controller) {
      queueMicrotask(() => controller.error(new Error('response leg lost')));
      // Replace with controller.close() for the clean-EOF case.
    },
  });

  return new Response(body, {
    headers: { 'content-type': 'text/event-stream' },
  });
}

The harness timestamps both client.onerror and the eventual settlement of client.ping({ timeout: 300 }). The full local asset lives in experiments/mcp-streamable-http-sse-pending-repro/, including raw logs and a version matrix.

SDK 1.29.0: transport error at 4 ms, request failure at 304 ms

The first local run used @modelcontextprotocol/sdk 1.29.0 on Node.js 22.18.0:

error:
  onerror = 4ms
  request rejected = 304ms
  final error = MCP error -32001: Request timed out

eof:
  onerror = none
  request rejected = 302ms
  final error = MCP error -32001: Request timed out

json-control:
  request resolved = 1ms

The interesting number is not 304 ms by itself. Production timeouts may be seconds or much longer. The important observation is the separation between two clocks: the transport already knows at about 4 ms that the SSE stream failed, but the JSON-RPC request does not reject at about 4 ms.

Clean EOF is even harder to observe. A stream ending cleanly is not proof that the matching JSON-RPC response arrived. In this minimal case, there is no onerror, no result and no request settlement until the timeout.

The current 1.30.0 release still reproduces the same lifecycle gap

Upstream Issue #2739 was opened on August 30, 2026 and reports Node 24.18.0 with SDK 1.26.0 and 1.29.0. Before treating that as yesterday's already-fixed bug, I checked npm and found @modelcontextprotocol/sdk 1.30.0 is the current release. I then reran the exact same local harness without changing the test logic.

The result remained consistent:

Scenario	1.29.0	1.30.0	What it shows
Erroring SSE fires `onerror`	~4 ms	~3 ms	Transport sees the stream failure quickly
Erroring SSE request rejects	~304 ms	~306 ms	Request still waits for timeout
Clean EOF request rejects	~302 ms	~302 ms	Still waits for timeout, with no `onerror`
JSON control resolves	~1 ms	~1 ms	Normal request settles immediately

So the claim I can support as of September 1 is specific: the v1 lifecycle gap reproduces locally on 1.29.0 and 1.30.0. I did not independently rerun 1.26.0; that version is upstream evidence, not XBSTACK test evidence.

The root problem is not “the timeout is too long”

The upstream cause analysis fits the local behavior. In the v1 path, send() starts _handleSseStream() without exposing the request-scoped stream's complete lifecycle as something Protocol can await. The reader error can reach the global onerror callback without directly settling the JSON-RPC request that owns this POST response. Clean EOF does not necessarily produce the same transport error signal.

The resulting state looks like this:

JSON-RPC request pending
        |
        +-- transport.send() already returned
        |
        +-- request-scoped SSE errored / reached EOF
        |
        +-- no matching JSON-RPC result/error
        |
        +-- Protocol has only request timeout left to settle the Promise

That is why better global network logging is not enough. The missing contract is request ownership: which SSE response leg belongs to which outbound request, and who rejects that pending request when the leg disappears before delivering all required responses?

Practical containment: distinguish ordinary JSON results from genuine streaming

If you control the server and the request only needs to return a normal JSON-RPC result, not a request-scoped stream, returning application/json is a reproducible containment for this particular v1 path.

The local JSON control resolved in about 1 ms on both tested SDK versions. The difference matters because the JSON response path is awaited by send(), allowing parsing success/failure to become a request outcome directly.

A minimal server response looks like this:

return new Response(
  JSON.stringify({
    jsonrpc: '2.0',
    id: message.id,
    result: {},
  }),
  { headers: { 'content-type': 'application/json' } },
);

This does not mean “stop using SSE in MCP.” If the response genuinely needs request-scoped streaming, switching it to JSON changes semantics and merely avoids the failing path. It does not repair it.

The second containment is a finite request timeout appropriate for the tool SLA and upstream network budget. This prevents an unbounded pending Promise. But it is still only a safety net. If the transport knows after 3 ms that the response leg is gone and the application waits another 30 seconds, the bug is still amplifying failure for almost 30 seconds.

What a real SDK fix needs to accomplish

I did not fork the SDK locally and present that as an upstream fix. For the #2739 boundary, a complete lifecycle repair needs at least these properties:

When a POST creates a request-scoped SSE response, the transport knows which JSON-RPC request IDs it owns.
The lifecycle resolves normally after all matching responses arrive.
If a non-resumable SSE body errors or reaches EOF first, the corresponding pending request rejects promptly.
If the caller times out or aborts, reconnect/resume work cannot continue detached from the request that created it.

This is different from closing the entire client whenever any SSE stream fails. A client may have concurrent work. The important property is request-scoped ownership and settlement, not a coarse connection-wide teardown.

Do not generalize this v1 result to MCP 2026-07-28 or TypeScript SDK v2

This boundary matters because the ecosystem is currently mid-migration. Issue #2739 uses v1 @modelcontextprotocol/sdk and negotiates 2025-11-25, which means the older initialize/initialized and session-era flow.

MCP 2026-07-28 changes the protocol core to stateless request/response, and the TypeScript SDK v2 packages reorganize the modern serving/client paths. The official v2 migration documentation also states that on a 2026-07-28 Streamable HTTP connection, aborting an in-flight request closes that request's SSE response stream as the protocol cancellation signal.

Therefore the supported conclusion is not “all MCP Streamable HTTP has this bug.” It is:

As of September 1, 2026, the v1 @modelcontextprotocol/sdk 2025-era StreamableHTTPClientTransport still reproduces #2739's pending-until-timeout behavior on current 1.30.0 when a request-scoped SSE response ends/errors before delivering the matching JSON-RPC result. The v2 / 2026-07-28 path needs separate testing.

If you are already migrating, use the MCP Streamable HTTP deployment and 2026-07-28 migration guide rather than designing a new architecture around this v1 workaround. If the failure is a malformed JSON-RPC message rather than a pending request, use the MCP -32700 Parse Error guide. If the request completes but the tool result is cut off, that is a different MCP Tool Call Result Truncated path. The MCP engineering hub connects these troubleshooting paths.

Production troubleshooting checklist

When a remote MCP tool call looks stuck and eventually reports only a timeout, I would inspect it in this order:

Record HTTP status and Content-Type. Is the POST using JSON or text/event-stream?
Timestamp transport errors. An early onerror combined with a much later request timeout is a strong lifecycle clue.
Verify that the SSE stream actually delivered the matching JSON-RPC id. HTTP 200 alone does not complete the request.
Separate error from clean EOF. Clean stream termination may be silent at the transport error hook.
Check for explicit abort, DELETE or timeout first. Cancellation paths overlap in symptoms but are not identical to #2739.
A/B a normal JSON response when the result does not need streaming. Immediate JSON settlement versus SSE timeout narrows the fault domain sharply.
Keep a finite request timeout. Treat it as a containment boundary, not the root-cause fix.

Final decision

This is more than a cosmetic “increase the timeout” problem. In a production MCP client, the dangerous part is state disagreement: observability already knows the SSE leg is gone while the application still treats the JSON-RPC request as running. At concurrency, those unnecessary pending requests consume task slots, retry budgets and upstream state.

My current routing decision is:

Maintaining a v1 client: keep explicit request timeouts and use JSON responses for non-streaming request results when you control the server.
Depending on request-scoped SSE: do not treat the JSON containment as a real fix; track the #2739 lifecycle repair.
Building or migrating to 2026-07-28: verify the v2/modern path separately instead of inheriting this v1 conclusion.
Operating production clients: log both the transport-error timestamp and the JSON-RPC request-settlement timestamp; the gap between them is itself valuable diagnostic evidence.

The exact reproduction, version matrix and raw logs are being published as a GitHub asset. If upstream ships a fix, I will use the same three scenarios as a regression test and update this page with the first verified fixed version.

Canonical article on XBSTACK：https://www.xbstack.com/en/ai/mcp-streamable-http-sse-pending-timeout/?utm_source=devto&utm_medium=referral&utm_campaign=article_distribution&utm_content=en%2Fmcp-streamable-http-sse-pending-timeout&ref=devto

标签：#AI #SoftwareEngineering #DeveloperTools #MCP #Streamable HTTP

How to Security-Check an MCP Configuration: Secrets, Shell, Remote MCP, and Permissions

xn — Mon, 31 Aug 2026 10:13:18 +0000

The configuration problems most likely to survive into production are often not JSON syntax errors. They are credential and permission boundaries that work well enough to be ignored: real credentials stored in config, an overly broad shell boundary, a remote MCP endpoint treated as an ordinary URL, authentication data copied into logs, or a read-only agent running with write privileges.

Static scanning is useful here, but the opposite failure mode is also common: treating every command, shell or env field as a critical vulnerability. Security findings need execution context.

1. Exposed credentials

The problem is not the name of an environment variable. The problem is a real secret value ending up in a file that can be committed, copied, logged or screenshotted.

A safer configuration stores only references or identifiers and injects the real value through a controlled runtime environment. Documentation, issues and screenshots should use redacted placeholders rather than production values.

MCP authorization guidance distinguishes HTTP and stdio transports. A local stdio process should not copy an HTTP OAuth flow; credentials should come from an appropriate local secure environment. Remote HTTP servers need explicit authorization boundaries such as protected-resource metadata, resource binding and appropriately scoped credentials rather than one long-lived credential copied into every client.

Before deployment, review whether the config is version-controlled, whether errors echo authentication fields, whether CI can copy credentials into public artifacts, and whether example config is likely to be pasted into a public repository.

2. Shell is not automatically a vulnerability

These are very different execution boundaries:

fixed executable + fixed working directory + constrained parameters

versus:

general command interpreter + model-controlled arguments + privileged identity

When a scanner finds bash, sh, powershell or another command execution surface, the next questions are more important than the keyword itself:

Can user or model input reach command arguments?
Is the working directory constrained?
Are arbitrary filesystem, network or child-process actions possible?
Does the process run with more privilege than the task needs?
Do mutating operations require authorization or confirmation?
Are commands and outputs copied into logs?

String matching can identify a review point. It cannot prove an arbitrary-command-execution vulnerability on its own.

3. A remote MCP endpoint is a trust boundary

Connecting to remote MCP is not the same as calling an ordinary content URL. The agent may receive Tools, Resources or Prompts from the server. Before trusting the connection, confirm:

The domain and documentation belong to the expected provider.
The endpoint uses HTTPS.
Authorization material is sent only to the intended resource.
Scopes are no broader than necessary.
Remote tool descriptions and returned content are treated as model input with appropriate validation.
Access can be revoked when the provider or connection changes.

Notion's MCP security guidance similarly tells users to verify official endpoints and reminds them that connecting MCP can expose the connected user's workspace permissions to the AI system using that connection. If the remote endpoint also needs protocol, catalog, and authorization preflight, continue with the read-only MCP Server preflight so configuration risk and protocol health stay separate.

4. Logging and retention are separate controls

A provider-level data control does not imply that your MCP client, agent memory, traces, application database and logs all have the same retention behavior.

Review these independently:

authentication headers in logs;
sensitive fields in tool arguments;
full request bodies in error logging;
trace retention;
local caches, memory and vector-store cleanup.

This is the same distinction covered in OpenAI ZDR and Agent data boundaries: provider controls and end-to-end agent retention are not interchangeable claims.

Run a browser-local static check

The XBSTACK Agent Security Auditor is designed as a browser-local static scanner. Paste redacted MCP/Agent configuration or code, and it reviews signals around credentials, shell boundaries, remote MCP, permissions, retention, logging and execution limits.

A useful workflow is:

1. Redact real credentials before copying anything
2. Run the local scan
3. Use each finding to locate the exact field
4. Decide whether it is a real risk or an intentionally constrained configuration
5. Fix the boundary
6. Scan again and keep before/after evidence

The evidence-plus-review step matters. A fixed read-only script may legitimately be launched through a shell; the scanner should surface the boundary, but the presence of bash alone does not prove arbitrary command execution.

Pre-deployment checklist

[ ] No real credentials in repository/config examples
[ ] Remote MCP endpoint matches provider documentation
[ ] HTTP authorization resource and scope match the intended service
[ ] Shell/command parameter sources are controlled
[ ] Filesystem and network permissions are task-scoped
[ ] Mutating operations require business authorization or confirmation
[ ] Logs do not retain secrets
[ ] Trace/Memory/DB retention has an explicit policy
[ ] Third-party MCP/dependency provenance is known
[ ] Test and production credentials are separated

If several of these are unknown, fix the boundaries before adding more tools.

Bottom line

MCP configuration security is not "remove every command" and it is not "OAuth means safe." The real questions are where credentials live, who can invoke what, under which execution identity, where data is retained, and who supplies remote capabilities.

Agent Security Auditor helps surface those configuration-level signals quickly and consistently. Production security still depends on code review, runtime permissions, server-side authorization, dependency governance and business-level tests.

Source and related reading

How to Test an MCP Server Before Production: Read-Only Inspector Preflight

xn — Mon, 31 Aug 2026 10:12:40 +0000

A common way to test an MCP server is to open an Inspector and immediately invoke a tool. That is not always the right first step for a production endpoint. The protocol and catalog layer can be verified with read-only requests before any business action is triggered.

MCP 2026-07-28 moves the core to stateless request/response and adds server/discover. It can return supported protocol versions, capabilities and server identity. You can then use tools/list, resources/list and prompts/list to check what the server currently exposes. For authenticated services, the HTTP authorization challenge is itself part of the preflight evidence.

What to check before production

I split preflight into six layers:

Endpoint — reachability, TLS, redirects and expected HTTP status.
Protocol — whether the endpoint supports 2026-07-28 or only a legacy lifecycle.
Discovery — whether server/discover returns valid JSON-RPC and useful capability/version information.
Catalogs — whether tools/list, resources/list and prompts/list return valid structures.
Authorization — whether unauthenticated access produces a correct 401/metadata/challenge instead of an opaque 500.
Operational signals — response time, cache hints and error consistency.

Once these pass, real tool calls are much easier to debug because you have already separated protocol failures from business logic failures.

Reading server/discover correctly

A modern MCP server implements server/discover. The response may expose:

supportedVersions;
capabilities;
server identity metadata;
optional instructions;
cache hints such as ttlMs and cacheScope.

Two details matter.

First, a client does not have to call server/discover before every request. The specification allows a client to send another RPC directly and handle UnsupportedProtocolVersionError if necessary.

Second, self-reported server information is useful for display and debugging, but it is not an authentication primitive. Real authorization still depends on OAuth, token audience, scopes and application-level checks.

Why validate the list methods too

server/discover tells you what the server says it supports. The list methods show what the endpoint currently exposes:

server/discover
  ->
tools/list
resources/list
prompts/list

If the capability metadata says Tools are supported but tools/list returns an invalid structure, you have a catalog implementation issue rather than a network issue. If a deployment unexpectedly returns zero tools, you can detect that before any real business action is attempted.

Why XBSTACK's public Inspector is read-only

The official MCP Inspector is a full developer tool with Web, CLI and TUI clients and support for tools/call. That is appropriate when a developer is debugging a server they control.

The XBSTACK MCP Inspector deliberately uses a narrower boundary for public remote endpoints: discovery, compatibility detection and first-page catalog reads, without sending tools/call.

The reason is operational context. A public web checker does not know what side effect an unknown tool may cause or whether the visitor is authorized to trigger it. So the product is closer to an MCP endpoint preflight than a complete interactive client.

The same probe now covers 15 public endpoints

The current MCP Protocol Radar applies the same read-only method to 15 public remote endpoints, including Context7, Microsoft Learn, DeepWiki, GitHub, Vercel, Atlassian Rovo and multiple Cloudflare MCP servers.

For each endpoint it records the same kinds of observations:

reachability;
modern / legacy / unknown classification;
protocol version;
tools/resources/prompts counts;
authorization challenge;
verification timestamp.

This is useful as a compatibility dataset. It should not be presented as a security ranking or official certification.

A practical rollout order

1. Read-only preflight in a public or controlled environment
2. Confirm protocol and authorization boundaries
3. Invoke read-only tools with a test account
4. Validate authorization/confirmation for write tools
5. Test failure, timeout, retry and duplicate-call behavior
6. Send production traffic

If step one already shows JSON-RPC parse errors, an empty catalog, a version mismatch or broken OAuth metadata, fix the foundation first. A successful business tool call should not be used to hide protocol-level defects.

What a read-only PASS means

It means the endpoint passed the checks that were actually executed at that timestamp.

It does not mean:

every tool works;
permissions are least-privilege;
tool output is free of prompt-injection risk;
the server has no application vulnerabilities;
a future deployment will behave the same way;
XBSTACK or the MCP project has certified the server.

That is why the radar keeps verifiedAt, stale state and methodology visible instead of assigning permanent safety labels.

If you only need to know whether a remote endpoint is healthy enough for deeper debugging, start with the MCP Inspector. If you want to compare protocol adoption across public servers, use the MCP Protocol Radar.

Source and related reading

How to Add WebMCP to a Website: Chrome 149 Forms, Tool Schemas, and registerTool

xn — Mon, 31 Aug 2026 10:08:57 +0000

If an older tutorial tells you to use navigator.webmcp, dump the entire page state into an agent, or treat WebMCP as a magical "AI clicks the website" layer, do not copy it blindly. In the current 2026 documentation, the model is clearer: the site explicitly registers structured tools, and an agent understands them through stable names, descriptions and input schemas.

Chrome 149 provides a WebMCP origin trial. On August 26, Chrome also published a new design guide that starts from user goals, state transitions and conversational paths instead of telling developers to convert every button into a tool.

The simplest path: expose an existing form

If the task is already a form submission—search, filtering, booking, lookup or another explicit request—the declarative API is a good starting point:

<form
  toolname="search_docs"
  tooldescription="Search XBSTACK technical documentation"
  action="/search"
>
  <input
    name="q"
    toolparamdescription="Technical topic or error message"
  />
  <button type="submit">Search</button>
</form>

The page still works like a normal form for people, while an agent gets a task name and parameter meaning. This is most useful when the user-visible UI already represents a coherent task.

Richer actions: document.modelContext.registerTool

For tasks that depend on client state, custom validation or non-trivial execution, the current imperative API uses document.modelContext.registerTool:

await document.modelContext.registerTool({
  name: 'inspect_agent_readiness',
  description: 'Inspect the current site for agent-readiness signals.',
  inputSchema: {
    type: 'object',
    properties: {
      url: { type: 'string', format: 'uri' }
    },
    required: ['url']
  },
  annotations: {
    readOnlyHint: true
  },
  execute: async ({ url }) => {
    return await inspectReadiness(url)
  }
})

The important part is the contract, not the syntax. The name should be stable and action-oriented. The description should explain when the tool is useful. The schema should constrain what the agent can submit. A mutating action must not be mislabeled as read-only.

Do not register every button

Chrome's August 26 guidance is useful here: start with a user goal, document the starting state and completion state, then identify meaningful state transitions.

On a commerce page, opening a details panel or switching tabs may be UI mechanics. Checking inventory, adding an item to a cart and placing an order are actual user tasks. Turning every DOM interaction into a tool creates a noisy tool catalog and makes selection harder.

A good WebMCP tool should map to a user task, not a CSS selector.

Security still belongs to your application

WebMCP exposes only the tools you register, but that does not replace authorization. Current Chrome security guidance recommends annotating genuinely read-only tools and constraining cross-origin exposure to trusted origins.

Deletion, payment, publishing, permission changes and other sensitive operations should still require server-side authorization, parameter validation, confirmations where appropriate, and audit records. The caller being an agent is not a reason to bypass the application's existing security model.

How to verify the integration

First, verify functionally in a browser environment that supports the experimental feature: make sure the tool registers, the schema is correct, execution returns the expected result and failure paths are explicit.

Second, use Lighthouse. Chrome now has a Registered WebMCP tools audit that lists tools registered through the declarative or imperative APIs. An empty result means Lighthouse did not observe a valid WebMCP tool on the page.

Third, run conversational evals. Express the same user goal in several ways and check whether the agent selects the intended tool, extracts the correct parameters and refuses or asks for clarification in invalid states.

Fourth, add production telemetry. Track tool exposure, start, success, error and meaningful post-action outcomes rather than looking only at page views.

WebMCP and llms.txt solve different problems

llms.txt v2 is about helping agents discover and understand content. WebMCP is about exposing structured actions once an agent is on an actionable page. One is primarily discovery; the other is operation. For the boundary between WebMCP and a standalone MCP Server, continue with the MCP protocol guide.

A more complete readiness stack looks like this:

robots / sitemap / canonical
        ->
llms.txt + Markdown discovery
        ->
clear page semantics
        ->
WebMCP tools where actions are useful
        ->
authorization / confirmation / telemetry

The XBSTACK Agent Readiness Auditor evaluates these layers separately. A site is not automatically agent-ready because it has /llms.txt, and registering one WebMCP tool does not make the whole site ready either.

Recommendation

For a first WebMCP experiment, choose one low-risk, read-only, easily verifiable task such as documentation search, product lookup or a readiness scan. Prove the schema, tool selection, error states and telemetry before expanding into write operations.

WebMCP is worth preparing for, but the technology is still experimental. Accurate version boundaries and fallbacks are more valuable than registering dozens of tools just to claim the site is "AI ready."

Source and related reading

How to Configure llms.txt v2: rel=alternate, describedby, and Markdown Discovery

xn — Mon, 31 Aug 2026 10:08:55 +0000

If your site already publishes /llms.txt, the August 2026 v2 update is less about adding more text and more about fixing discovery. Previously, an agent that landed on an HTML page often had to guess whether a Markdown representation existed or whether the site exposed an llms.txt file. v2 adds explicit relationships for both cases.

Use rel="alternate" type="text/markdown" to point to a Markdown representation of the current page, and rel="describedby" to identify the llms.txt that applies to the page. These relationships solve a machine-discovery problem. They are not a shortcut to conventional search rankings.

What changed in v2

The official v2 change notes put discoverability first. A page can publish:

<link rel="alternate" type="text/markdown" href="/docs/example.md">
<link rel="describedby" href="/llms.txt">

The same relationships can also be delivered through an HTTP Link header. The first tells an agent that a cleaner Markdown representation is available. The second points the agent to the llms.txt that describes the relevant site or documentation scope.

That is materially better than requiring every agent to guess whether /page/ maps to /page.md, /page.html.md, a content API or nothing at all.

How I would deploy it on a real site

Do not start by generating a Markdown mirror for every archive and tag page. Prioritize pages where a machine-readable representation has clear utility.

The first tier is developer documentation and tools: API references, MCP pages, agent documentation and tool instructions. Code, parameters and constraints survive more cleanly in Markdown than in a heavily styled application page.

The second tier is high-value tutorials and troubleshooting guides. Keep the HTML version optimized for people, but expose an equivalent Markdown representation for agents. The two versions should carry the same claims and constraints; the Markdown page must not become a separate keyword-stuffing surface.

The third tier is navigation and archive pages. Many of these do not need a dedicated Markdown copy at all. They simply need to lead agents toward the important content through ordinary links, sitemap coverage and a useful llms.txt file.

Verification checklist

Do not stop after seeing two <link> elements in source code. Verify the actual chain:

The HTML page returns 200 and has the intended canonical URL.
The rel=alternate Markdown URL returns 200 and matches the page's meaning.
The rel=describedby target returns the expected llms.txt content rather than an HTML error page.
robots.txt and access controls do not contradict the machine-readable paths you just exposed.

For multilingual sites, verify that Markdown, canonical, hreflang and llms.txt scope stay language-consistent. A Chinese page that points an agent to an English-only machine representation can create a new discovery mismatch even if the HTML hreflang setup is correct.

What llms.txt is not

It is not robots.txt. robots.txt primarily governs crawler access and path rules; llms.txt is closer to a curated map and context layer for agents.

It is not sitemap.xml. A sitemap enumerates URLs for search systems, while llms.txt highlights context and useful machine-readable material.

And it is not a documented SEO ranking switch. The practical value of v2 is reducing guessing and making machine discovery explicit. That is useful on its own and does not require inventing a ranking promise. If the page also needs to expose structured actions after discovery, the next layer is WebMCP on Chrome 149; discovery and operation are separate concerns.

Check the whole readiness chain

The XBSTACK Agent Readiness Auditor treats llms.txt as one part of a broader chain: machine entry points, robots and sitemap health, content discovery, Markdown/llms.txt signals, and agent-operable capabilities should be evaluated separately.

A useful mental model is:

Agent discovers site
  -> discovers llms.txt
  -> discovers the target page
  -> optionally finds the Markdown representation
  -> understands page constraints
  -> uses WebMCP or MCP only when an actionable tool layer is actually present

That is why the two v2 link relations matter more than arguments about an ideal llms.txt word count. They turn part of agent discovery from convention and guessing into an explicit relationship controlled by the site.

Bottom line

If you already publish llms.txt, add rel=describedby where it helps agents locate the correct file. Where important documentation or tool pages have a stable Markdown representation, expose it with rel=alternate type="text/markdown". Then test the real HTTP responses and track whether the machine entry points are actually used.

If you do not yet have llms.txt, avoid generating a giant keyword directory just because "AI SEO" is fashionable. First make the site structure and important pages coherent, then use the Agent Readiness Auditor to identify the discovery gaps worth fixing.

Source and related reading

n8n Execution Stuck Running After Success: Zombie Execution When Successful Runs Are Not …

xn — Sat, 29 Aug 2026 03:55:29 +0000

A production-focused update based on a real project: n8n execution stuck running after success? On 2.36.6, a webhook can return 200 while execution_entity stays running. This A/B …

If your n8n production webhook already returned HTTP 200 and the business action finished, but the corresponding database row still looks like this long afterward:

finished = false
status = running
stoppedAt = NULL

do not assume the node is still executing or the Task Runner is hung. I reproduced a much narrower failure on the official n8nio/n8n:2.36.6 image: same instance, same SQLite database, same three-node Webhook → Set → No Operation workflow, with only Save successful production executions changed.

With Do not Save (saveDataSuccessExecution=none), the production webhook returned 200 but execution_entity kept finished=0 / status=running / stoppedAt=NULL. In the control, changing only the setting to Save (all) produced finished=1 / status=success and a normal stoppedAt timestamp.

n8n's upstream issue #37040, opened on August 25, 2026, reports the same symptom on n8n 2.36.6 + PostgreSQL + regular execution mode. At publication time the issue is still open, marked status:in-linear, with no linked fix PR. This is therefore not enough evidence to blame SQLite or PostgreSQL alone, and it is also not evidence that every execution stuck in running is this bug.

Check whether you have this specific zombie execution

The confusing part is that the workflow looks complete from the caller's perspective while the database says otherwise. This article is a good match when most of these conditions are true:

It is a production execution such as a production Webhook.
The webhook or business action already succeeded rather than a node actually blocking.
Save successful production executions is set to Do not Save.
The matching execution_entity row shows finished=false, status=running, and an empty stoppedAt.
Similar successful runs keep accumulating instead of eventually closing as success.

If runData is empty, the node never starts, a Code node reports Task request timed out, a Schedule Trigger is not dispatching, or a container restart is required before work continues, the search phrase may still be “n8n stuck running” but the failure can be different. Upstream issue #36886, for example, describes a genuinely stuck execution path. The case here is specifically completed work whose persisted final state was not closed.

Minimal reproduction: change one setting

I deliberately avoided AI Agent nodes, external APIs, database nodes, and complex expressions. Both workflows are only:

Production Webhook
      ↓
Set { ok: true }
      ↓
No Operation

They use the same n8n 2.36.6 instance, database and nodes. The only intended variable is:

experiment: saveDataSuccessExecution = none
control:    saveDataSuccessExecution = all

Both production webhooks returned:

HTTP/1.1 200 OK

{"message":"Workflow was started"}

I then queried SQLite directly:

SELECT id,
       workflowId,
       finished,
       status,
       mode,
       startedAt,
       stoppedAt,
       storedAt,
       jsonSizeBytes
FROM execution_entity
ORDER BY id DESC;

The result:

workflowId                 finished  status   stoppedAt
-------------------------  --------  -------  -----------------------
xbstackZombieControl2366   1         success  2026-08-29 02:10:30.826
xbstackZombie2366          0         running  NULL

That control matters because it removes several common confounders: the webhook itself did not fail, the workflow was not complex, and the two cases did not use different n8n versions. On this n8n 2.36.6 SQLite instance, changing successful execution storage from none to all also changed whether the execution row finalized correctly.

The importable workflow JSON files, exact SQL output, and version matrix are published in the GitHub reproduction asset.

Why this matters beyond a stale UI status

If only the browser UI failed to refresh, the operational impact would be limited. Here the persisted row itself remains:

finished = false
status = running
stoppedAt = NULL

That can distort or complicate:

counts of genuinely running executions;
execution-history and monitoring queries;
pruning and retention behavior around abnormal rows;
operational scripts that check for unfinished work;
database growth and execution-history governance.

So if business actions succeed while running rows accumulate, refreshing the UI is not an adequate diagnosis.

The safest workaround I can verify today

As of August 29, 2026, issue #37040 has no public fix PR, so I will not claim that a particular upgrade solves it. The only mitigation directly verified by this A/B is:

If your privacy, retention, and storage policy permits it, temporarily change Save successful production executions from Do not Save to Save, and control retention with execution pruning.

This is evidence-based rather than speculative: the saveDataSuccessExecution=all control on the same three-node production webhook finalized correctly.

It is not a permanent fix. Saving successful executions increases stored execution data, so evaluate retention windows, pruning configuration, and whether workflow data can contain sensitive business or user content.

Do not use a direct database UPDATE as the generic fix

A table full of rows like:

finished = 0
status = running
stoppedAt = NULL

makes a bulk UPDATE execution_entity tempting. I do not recommend that as a generic repair.

execution_entity is not just a display table. Execution state can interact with execution data, pruning, insights, metadata, and lifecycle logic. Changing running to success does not prove related state is consistent.

If production already contains many zombie rows, a safer order is:

take a complete database backup;
verify that the save-none condition matches this reproduction;
reproduce it in an isolated environment;
enable successful execution saving temporarily and confirm new executions close normally;
wait for upstream cleanup guidance, or design a version-specific migration only after understanding the exact schema and related rows.

PostgreSQL versus SQLite: the evidence boundary

The upstream #37040 reporter used PostgreSQL. This XBSTACK A/B used SQLite and produced the same:

finished = false
status = running
stoppedAt = NULL

That means the evidence does not support calling this PostgreSQL-specific. However, I did not complete an independent local PostgreSQL reproduction because Docker Hub repeatedly timed out while pulling postgres:16-alpine.

The defensible summary is therefore:

PostgreSQL: real upstream report in n8n issue #37040;
SQLite: independent XBSTACK A/B reproduction;
shared condition: n8n 2.36.6 with successful execution saving disabled;
root cause: not publicly finalized by the upstream project yet.

How to retest once a fix is released

When #37040 gains a linked PR or a release explicitly fixes it, do not rely on the changelog alone. Re-run the same minimal fixture:

Webhook → Set → No Operation
saveDataSuccessExecution = none

and verify that successful runs no longer leave:

finished=0 / status=running / stoppedAt=NULL

Then re-run the saveDataSuccessExecution=all control to make sure normal saved successful executions still finalize correctly.

The public reproduction keeps both workflow JSON fixtures and the original result so future releases can be compared against the same test rather than a moving target.

Bottom line

If an n8n production workflow has already succeeded but the execution remains running with finished=false and stoppedAt=NULL, check whether Save successful production executions is set to Do not Save before diagnosing a genuinely hung node.

On n8n 2.36.6, the SQLite A/B here and the upstream PostgreSQL report point to the same execution-finalization boundary. There is no public final fix yet. The most defensible current mitigation is to evaluate enabling successful execution saving plus pruning, rather than bulk-editing execution states in the database.

Related troubleshooting:

Canonical article on XBSTACK：https://www.xbstack.com/en/ai/n8n-zombie-execution-save-none/?utm_source=devto&utm_medium=referral&utm_campaign=article_distribution&utm_content=n8n-zombie-execution-save-none&ref=devto

标签：#AI #SoftwareEngineering #DeveloperTools #n8n #Workflow

n8n Code Node 'Task request timed out': Fix 'Not Matched to a Runner'

xn — Wed, 26 Aug 2026 06:34:54 +0000

A production-focused update based on a real project: n8n Code Node reports Task request timed out / not matched to a runner. Reproduce it on 2.37.1, distinguish runner wait from J…

If an n8n Code node is not throwing a JavaScript syntax error but instead waits for roughly a minute and then fails with:

Task request timed out
Your Code node task was not matched to a runner within the timeout period

do not start by rewriting the return statement, loops, or input data. This error first means the Code task was not accepted by a matching Task Runner before the N8N_RUNNERS_TASK_REQUEST_TIMEOUT deadline. XBSTACK reproduced the exact path with official n8nio/n8n:2.37.1 and n8nio/runners:2.37.1 images in external mode: remove the runner and a one-line Code node times out; register the JavaScript runner and the same workflow passes; start the runner after the request is already waiting but before the deadline and the pending task is accepted without a manual retry. For self-hosted n8n, inspect runner registration, broker reachability, auth, image versions, worker placement and capacity. For n8n Cloud, use a minimal Code canary to separate platform runner failure from business logic, then take the execution evidence to n8n Support. Increasing the request timeout only extends the waiting window; it does not repair a runner that never becomes available.

What the error actually means: this is not ordinary JavaScript execution timeout

n8n's current Task Runner architecture has three relevant roles:

Code node / task requester
          ↓
      task broker
          ↓
 available task runner
          ↓
   execute JavaScript

The official docs describe runners connecting to the broker over WebSocket. The Code node is the task requester: it submits a task to the broker, and an available runner accepts and executes it. If no matching runner accepts the request before the deadline, the requester receives Task request timed out.

That is a different phase from “the runner accepted my task and the JavaScript itself ran too long.”

Two current environment variables are easy to confuse:

Setting	Current documented default	What it limits
`N8N_RUNNERS_TASK_REQUEST_TIMEOUT`	60 seconds	How long a task request may wait for an available runner
`N8N_RUNNERS_TASK_TIMEOUT`	300 seconds	How long an accepted task may execute before the runner stops it

If the error explicitly says:

was not matched to a runner within the timeout period

your first question should be why no runner accepted the task, not how to make the JavaScript faster.

XBSTACK reproduction: no runner, healthy runner, and recovery while waiting

To remove workflow complexity and Cloud-specific internals from the test, I used official Docker images on a Linux x86_64 NAS:

Docker 28.5.2;
n8nio/n8n:2.37.1;
n8nio/runners:2.37.1;
external runner mode;
default SQLite;
no credentials;
no external APIs;
only Manual Trigger -> Code.

The Code node contains one statement:

return [{ json: { ok: true, source: 'xbstack-task-runner-repro' } }];

For the negative control, I shortened N8N_RUNNERS_TASK_REQUEST_TIMEOUT from the current documented default of 60 seconds to 15 seconds so the failure would not take a full minute each run. The mechanism stays the same.

Control 1: external mode with no matching runner

Result: failure after about 15.04 seconds.

n8n logs:

n8n Task Broker ready on 0.0.0.0, port 5679
Task request timed out
Error: Task request timed out

The execution description says:

Your Code node task was not matched to a runner within the timeout period
(waited 15 seconds).
This indicates that the task runner is currently down, or not ready,
or at capacity, so it cannot service your task.

The Minimal Code execution time was about 15040 ms. That does not mean the one-line JavaScript consumed 15 seconds of CPU. It means the task spent the window waiting for a JavaScript runner that never accepted it.

Control 2: matching JavaScript runner registers normally

With n8nio/runners:2.37.1 attached as the external sidecar, the n8n log records:

Registered runner "launcher-javascript"
Registered runner "JS Task Runner"

The same Code node then returns:

{
  "ok": true,
  "source": "xbstack-task-runner-repro"
}

Control 3: request starts first, runner starts before the deadline

This third run is the clearest demonstration of what the request timeout means.

I started the n8n CLI execution first, letting the Code task wait at the broker with no runner container active. Then I started the matching n8nio/runners:2.37.1 sidecar before the 15-second deadline.

The workflow did not need a manual retry. After the JS runner registered, the already-pending task was accepted and the workflow completed after about 8.42 seconds.

The operational takeaway is straightforward:

N8N_RUNNERS_TASK_REQUEST_TIMEOUT is the “how long am I willing to wait for a runner?” window, not the “how long may my JavaScript execute?” limit.

The minimal workflow, sanitized logs and version matrix are stored in the XBSTACK reproduction asset for this issue cluster.

Fastest diagnosis: create one tiny Code canary first

If the failing workflow has dozens of nodes, agents, APIs and database writes, do not debug all of that at once.

Create:

Manual Trigger
  ↓
Code

Use:

return [{ json: { ok: true } }];

Then branch the diagnosis.

Case A: the minimal Code node fails with the same runner timeout

Business logic, model API keys and input payloads are no longer your first suspects. Check:

is the runner actually running;
did it successfully register with the broker;
is a JavaScript runner available, not only Python;
can the runner container reach the broker;
do both sides use the same auth token;
are all runner concurrency slots occupied;
which worker received the execution, and does that worker have its own sidecar.

Case B: the minimal Code node succeeds, but one workflow still fails

Do not force every failure into the infrastructure bucket. Continue with:

genuinely long-running Code;
infinite loops or CPU-heavy synchronous work;
very large inputs;
modules missing from or not allowlisted in the runner image;
a trigger-specific dispatch difference between Schedule, Webhook and Manual runs.

That final case matters because n8n #37065 is narrower than the generic timeout reproduced here: the report says the external runner is healthy, webhook/manual JavaScript runs pass, but scheduled JavaScript is not dispatched. That is a trigger-path/dispatch difference, not proof that every runner timeout is caused by a missing sidecar.

Self-hosted n8n: check these in order before changing the timeout

1. Confirm internal vs external runner mode

n8n currently recommends external mode for production so n8nio/runners runs as an isolated sidecar.

A minimal n8n-side configuration includes:

environment:
  N8N_RUNNERS_MODE: external
  N8N_RUNNERS_BROKER_LISTEN_ADDRESS: 0.0.0.0
  N8N_RUNNERS_AUTH_TOKEN: your-shared-secret

Runner sidecar:

environment:
  N8N_RUNNERS_TASK_BROKER_URI: http://n8n:5679
  N8N_RUNNERS_AUTH_TOKEN: your-shared-secret

One easy miss: the broker listens on localhost by default. In a multi-container setup, the official docs call out N8N_RUNNERS_BROKER_LISTEN_ADDRESS=0.0.0.0 so the sidecar can reach it.

2. Match the n8n and runners image versions

The external-runner documentation explicitly says the n8nio/runners image version must match the n8nio/n8n version.

For example:

n8nio/n8n:2.37.1
n8nio/runners:2.37.1

Do not upgrade the main container and leave the sidecar pinned to an unrelated tag, then start editing the workflow first.

3. Look for runner registration, not only `docker ps = Up`

A sidecar container being Up proves only that the container process exists. It does not prove the JavaScript task runner has joined the broker.

Useful log lines look like:

Registered runner "launcher-javascript"
Registered runner "JS Task Runner"

In the healthy control, n8n briefly saw only a Python offer while the pending task required JavaScript:

No matching task offer ... (type "javascript"). Available offer types: [python]

The task proceeded only after the JS runner registered.

4. Verify auth and broker reachability

The n8n container and the runners container must share the same:

N8N_RUNNERS_AUTH_TOKEN

The runner also needs a reachable:

N8N_RUNNERS_TASK_BROKER_URI

In Docker Compose that usually means a service name, for example:

http://n8n:5679

Do not blindly use localhost:5679 from a separate sidecar. Inside that container, localhost points back to the runner container itself.

5. In Queue Mode, every execution worker needs its own sidecar

The official docs state that each worker needs a Task Runner sidecar in Queue Mode.

If manual executions pass but production executions fail, ask:

Did both executions run on the same n8n process/worker?

If OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=false, the main instance can execute manual runs itself, so the main instance also needs an appropriate sidecar.

6. Check capacity before assuming the runner crashed

The current documented default for N8N_RUNNERS_MAX_CONCURRENCY is 5. If all runner slots are busy with long tasks, a new request can sit at the broker until its request timeout expires and produce the same high-level message.

So the same error can reflect:

runner container not started;
runner started but never registered;
auth/network prevents broker connection;
no matching JavaScript/Python runner type;
runner capacity is exhausted;
one worker lacks a sidecar;
a runner process repeatedly crashes during startup.

The message tells you the task was not accepted in time. It does not, by itself, tell you why.

Why changing 60 seconds to 300 seconds is not the first fix

n8n's own error text points to:

N8N_RUNNERS_TASK_REQUEST_TIMEOUT

That can be appropriate when you already know the runners eventually become available but need more time because of cold start or short-lived saturation.

It is not a root-cause fix for:

runner container down
AUTH_TOKEN mismatch
wrong broker URI
broker bound only to localhost
JS runner crashes during startup
worker has no sidecar

In those cases:

60s -> 300s

only turns “fail after one minute” into “fail after five minutes.” It can also mislead operators into thinking the workflow is actively executing when the Code task has not even been accepted yet.

n8n Cloud: do not copy self-hosted Docker commands

Several Cloud reports appeared on August 25-26, 2026:

#37069: n8n Cloud 2.37.1; even a blank workflow with a minimal Code node cannot get a runner;
#37062: similar 2.37.1 Cloud symptom with additional users reporting the same behavior;
#37043: JavaScript Code node timeout with a Cloud 2.37.1 confirmation in comments;
#36989: the same high-level timeout was also reported on Cloud 2.35.4.

That is enough to justify investigating the search problem, but not enough to title the article “n8n 2.37.1 confirmed regression.”

On August 25, GitHub releases showed the stable tag at 2.36.7 and the beta tag at 2.37.1. Issue #37064 proposed a 2.37.x / Node 26 runner-image regression hypothesis, but a maintainer closed the issue and said they were not seeing the same behavior on their own Cloud or self-hosted instances. There is no official evidence yet that every 2.37.1 instance shares one root cause.

For Cloud, the highest-value workflow is:

create Manual Trigger -> Code;
return only {ok:true};
record the n8n version;
record the waited 60/66 seconds detail;
preserve Execution / Debug Info;
if the canary fails too, send that evidence to n8n Support.

You cannot directly inspect or restart n8n Cloud's internal runner sidecar and broker the way a self-hosted operator can.

Is this the same issue as the ARM64 `GLIBC_PRIVATE` Task Runner failure?

No.

XBSTACK's existing n8n 2.33.7 distroless ARM64 GLIBC_PRIVATE reproduction covers a different failure boundary: the Python runner process exits immediately with code 127 and a libc symbol lookup error.

This article covers:

Code task submitted
↓
waiting for matching runner
↓
not accepted before deadline
↓
Task request timed out

A runner-process crash can be one reason no runner becomes available, but the high-level not matched to a runner error does not imply GLIBC or ARM64 by itself.

For the full deployment baseline, see Self-hosted n8n: Docker Compose, Postgres, VPS and NAS production setup. If the runner accepts the task and the node itself fails, retries, or needs centralized failure handling, see n8n Error Handling: Error Workflow, Retry On Fail, timeouts and reruns.

Practical checklist

When you see:

Task request timed out
Your Code node task was not matched to a runner within the timeout period

work through this order:

reduce to Manual Trigger -> Code;
determine whether every Code node fails;
self-hosted: confirm internal vs external runner mode;
verify the matching JS/Python runner actually registers;
confirm n8n and runners image tags match;
compare N8N_RUNNERS_AUTH_TOKEN on both sides;
verify N8N_RUNNERS_TASK_BROKER_URI and broker listen address;
in Queue Mode, confirm the execution's worker has its own sidecar;
check concurrency and long-running tasks;
only then decide whether a larger request timeout is justified;
on Cloud, if the minimal canary still fails, escalate with evidence instead of rewriting JavaScript.

Fix status: there is no universal “upgrade to this version” answer yet

As of 2026-08-26, this error string describes a symptom boundary, not one single upstream bug ID.

The recent Cloud cluster is worth monitoring, but the available evidence does not support either of these shortcuts:

all 2.37.1 instances = one Task Runner regression

or:

increase the request timeout = fixed

A better production control is a tiny Code canary plus explicit checks for runner registration, broker reachability and runner capacity after deployment. That makes the next occurrence much easier to classify as platform-instance trouble, runner infrastructure trouble, or a workflow/trigger-specific problem.

References and reproduction assets

Official references:

Recent upstream reports:

The complete minimal workflow, no-runner log, healthy-runner control, start-while-waiting recovery control, and version matrix are public in the XBSTACK n8n Code Node Task Runner timeout reproduction repository. The source project also keeps the same assets under experiments/n8n-code-node-task-runner-timeout-repro/ for future version regression runs.

Canonical article on XBSTACK：https://www.xbstack.com/en/ai/n8n-code-node-task-runner-timeout/?utm_source=devto&utm_medium=referral&utm_campaign=article_distribution&utm_content=n8n-code-node-task-runner-timeout&ref=devto

标签：#AI #SoftwareEngineering #DeveloperTools #n8n #Code Node

OpenAI Assistants API Migration: Why Responses API Should Be Your New Architecture

xn — Fri, 21 Aug 2026 07:06:55 +0000

OpenAI Assistants API Migration: Why Responses API Should Be Your New Architecture

OpenAI Assistants API is moving toward shutdown, and projects built around Assistant, Thread and Run abstractions need a migration plan.

This article explains:

why simply replacing old APIs is risky
how to separate instructions, tools, state and business logic
when Responses API is enough
when a custom AI Agent architecture is still required

Full technical migration guide:

https://www.xbstack.com/ai/openai-assistants-api-vs-custom-agent/

OpenAI Zero Data Retention for AI Agents: What ZDR Does—and Does Not—Cover

xn — Thu, 20 Aug 2026 07:21:55 +0000

This article focuses on one production misconception: enabling OpenAI Zero Data Retention does not, by itself, make an entire AI Agent system zero-retention.

The easiest mistake to make with OpenAI Zero Data Retention (ZDR) is to turn a provider-level data control into an end-to-end architecture claim:

“If ZDR is enabled, this AI agent does not retain data anywhere.”

That is not what the current OpenAI documentation says.

As of August 20, 2026, OpenAI's Data Controls documentation says eligible customers can be approved for Zero Data Retention and configure it at the API organization or project level. With ZDR enabled, customer content is excluded from eligible abuse-monitoring logs and the store parameter for /v1/responses and /v1/chat/completions is always treated as false.

A production agent, however, usually has a much larger data path:

User / Enterprise Data
        ↓
Application / Agent Runtime
        ↓
OpenAI Responses API        ← ZDR controls part of this retention surface
        ↓
Remote MCP / Tools          ← third-party retention policy
        ↓
SaaS / Database / Files     ← business-system retention
        ↓
Agent Memory / Vector DB    ← your application state
        ↓
Trace / Audit / SIEM        ← your audit policy

The useful question is therefore not “Does OpenAI support ZDR?” It is: after ZDR is enabled, where else can an enterprise agent still persist data, and how should those boundaries be governed?

First separate three concepts that are often conflated

1. `store=false`

This is part of endpoint/request behavior. For the Responses API, OpenAI documents application-state behavior around store; when organization-level ZDR is enabled, store is treated as false even if a request tries to set it to true.

2. Zero Data Retention

ZDR is an approval-based OpenAI data control, not a flag that every API key has by default. Approved customers can configure it at the organization or project level.

OpenAI separates at least two storage categories:

Abuse monitoring logs, which can contain prompts, responses and related metadata and are retained for up to 30 days by default under the documented policy;
Application state, which some API capabilities persist in order to perform a feature.

ZDR changes the first category and changes application-state behavior for ZDR-eligible endpoints, but it does not automatically make every API feature or external tool zero-retention.

3. Data Residency

Data Residency answers where eligible customer content is stored or processed. ZDR answers whether and how long relevant content is retained.

They are different control planes. A regulated agent deployment may need both a residency design and a retention design.

The OpenAI boundaries that matter most for agent builders

The table below is more useful than a binary “supports ZDR” label.

Agent component / API capability	Current documented boundary	Architectural implication
`/v1/responses`	ZDR forces `store=false`	Useful for stateless model calls, but tool/state choices still matter
`/v1/chat/completions`	ZDR forces `store=false`	Does not imply downstream systems are zero-retention
`/v1/conversations`	Listed as not ZDR-eligible; state persists until deletion	Do not treat Conversations as stateless storage in a strict ZDR design
`/v1/vector_stores`	Not ZDR-eligible; application state persists until deletion	Vector knowledge needs its own retention policy
`/v1/files`	Not ZDR-eligible; files persist until deletion/expiry rules	Uploaded files need explicit TTL and deletion controls
Remote MCP	Third-party service	Governed by the MCP provider's own retention policy
Background Mode	Response data is written to disk for roughly 10 minutes for polling	Strict zero-persistence use cases need feature-level review
Hosted Shell / Code Interpreter containers	Temporary application state can exist while containers are active	Sandbox lifecycle is also a data lifecycle
Prompt Caching	Encrypted KV tensors may be kept in GPU-local storage with a documented maximum 24-hour expiration boundary	“No database record” does not mean “no temporary state”
Third-party network services	Third-party policy applies	OpenAI ZDR cannot govern external SaaS retention

The most consequential sentence for agent architecture is explicit in OpenAI's guide: MCP servers are third-party services, and data sent to an MCP server is subject to that server's data-retention policy.

If an agent sends customer contracts, source code, financial data or internal tickets to a remote MCP server, OpenAI-side ZDR does not tell you whether that MCP provider logs, caches, forwards or stores the content.

Why ZDR has to be designed with MCP security

The MCP specification already treats tools as a security-sensitive execution surface.

The current MCP Specification notes that MCP can expose arbitrary data access and code-execution paths and therefore requires consent, authorization, data protection and tool-safety thinking. The Tools specification requires servers to validate inputs, implement access controls, rate-limit invocations and sanitize outputs; clients should confirm sensitive operations and log tool usage for audit.

Those controls answer different questions from ZDR:

ZDR                 → OpenAI-side data-retention control
MCP Authorization   → who may invoke which tool
MCP Server Policy   → how the tool provider processes and stores data
Sandbox             → what the tool can actually affect
Audit               → whether the execution chain can be reconstructed

An enterprise agent needs a data-flow inventory, not one zdr_enabled=true checkbox.

Build a retention matrix, not a marketing claim

A practical architecture review should have a table like this:

Data flow	Data type	Processor	Persisted?	Default TTL	Delete path	Owner
User → Agent Runtime	Raw request	Your app	Business-dependent	Custom	DB/API	Application owner
Runtime → OpenAI Responses	Prompt/context	OpenAI	Feature/control-dependent	Official policy	Endpoint-dependent	AI platform
Agent → Remote MCP	Tool args/context	Third-party MCP	Provider-dependent	Unknown is a risk	Provider policy	Integration owner
Agent → Vector DB	Embeddings/chunks	First/third party	Usually yes	Custom	Delete/TTL	Data owner
Agent → Audit	Tool event/approval	SIEM/log store	Yes	Minimum necessary	Retention rule	Security

If the team cannot complete this matrix, it should not describe the system as a “zero-retention agent architecture.”

ZDR and audit logs are not opposites

Another failure mode is turning “zero retention” into “turn off every useful security log.” That is not a safe production pattern.

OpenAI's Running Codex safely at OpenAI describes a deployment model that combines sandboxing, approvals, network policy, identity/credentials and agent-native telemetry and audit trails. OpenTelemetry events can cover tool approval decisions, tool execution results, MCP server usage and network allow/deny decisions.

The better question is:

Which content should not be retained, and which minimal security events must be retained so an incident can still be investigated?

A high-risk agent audit record can often store structured evidence without copying the full sensitive payload:

{
  "actor_id": "user_or_service_hash",
  "tenant_id": "tenant_123",
  "tool": "invoice.approve",
  "resource_id": "invoice_***",
  "decision": "approved",
  "approval_id": "appr_***",
  "arguments_hash": "sha256:...",
  "result": "success",
  "timestamp": "..."
}

That is the design tension to solve: data minimization without losing auditability.

Why ZDR belongs inside Agent Security Infrastructure

The broader industry signal is now stronger than a single vendor feature.

NIST's 2026 analysis of responses on AI agent security says commenters widely agreed that agents introduce novel security threats and that those concerns are a barrier to adoption. NIST is also pursuing a dedicated software and AI agent identity and authorization effort.

The OWASP Top 10 for Agentic Applications 2026 treats Tool Misuse, Identity & Privilege Abuse, Unexpected Code Execution, Memory & Context Poisoning and related agent-specific risks as a distinct security domain.

The International AI Safety Report 2026 places deployment-time monitoring, human oversight, chain-of-thought monitoring and sandboxing inside the technical-safeguard toolbox and explicitly emphasizes the limitations of individual safeguards and the need for defense in depth.

That leads to a more durable infrastructure stack than model routing alone:

Identity
   ↓
Authorization / Policy Gate
   ↓
Approval
   ↓
Sandbox + Network Boundary
   ↓
Tool / MCP Execution
   ↓
Data Retention Policy
   ↓
Audit / Monitoring
   ↓
Incident Response / Kill Switch

ZDR is one component of the Data Retention layer.

How I would design a ZDR-aware enterprise agent

Step 1: classify data before choosing controls

At minimum, distinguish:

Public
Internal
Confidential
Regulated / PII / PHI / Financial

The classification determines whether data may enter the model, remote MCP, long-term memory or logs.

Step 2: create a data-egress record for every tool

Track at least:

Provider
Authentication identity
Data categories
Retention policy
Region
Write capability
Approval requirement
Audit event

Step 3: treat unknown third-party retention as a risk

This matters most for remote MCP. Standardized transport does not imply standardized retention. If the provider policy, contract or self-hosted boundary is unknown, do not treat it as covered by OpenAI ZDR.

Step 4: set explicit TTLs for every persistent state

Review:

Application databases
Agent memory
Vector stores
Uploaded files
Traces
Audit logs
Temporary sandboxes

Every state should answer: why is it needed, how long can it exist, and who can delete it?

Step 5: make deletion verifiable

A production retention policy should be executable:

list retained objects
→ identify owner / tenant
→ delete or expire
→ verify deletion
→ retain deletion evidence

Production checklist

Before describing an OpenAI-powered agent as ZDR-aware, verify:

[ ] Has the organization/project actually been approved for ZDR, rather than only using store=false?
[ ] Are the endpoint and features in use ZDR-eligible?
[ ] Are Conversations, Vector Stores or Files used anywhere in the flow?
[ ] Is Background Mode enabled?
[ ] Is prompt caching enabled?
[ ] Are hosted shell or Code Interpreter containers used?
[ ] Is remote MCP connected, and has each third-party retention policy been reviewed?
[ ] Do application memory, databases, traces and audit stores have explicit TTLs?
[ ] Have Data Residency and ZDR been reviewed separately?
[ ] Do logs minimize sensitive content while preserving tool/approval accountability?
[ ] Is there a tested deletion and credential-revocation procedure?

If a critical item is answered with “we don't know,” the architecture is not ready to be described as zero-retention.

Bottom line

Zero Data Retention is a meaningful enterprise control, but it is not a magic label that makes an entire agent stack stateless.

A production agent's data boundary has to extend from the model API through MCP, tools, memory, sandboxes, audit systems and third-party SaaS.

That is why the more durable enterprise opportunity is broader than model routing or token-cost management. It is AI Agent Security Infrastructure: the control plane for identity, permissions, execution, data, audit and incident response.

Continue with:

Primary references

Original article and related reading

n8n 2.35.3: Why $json.data.sort() Returns null

xn — Wed, 19 Aug 2026 09:01:29 +0000

This is not a generic 'your array is malformed' diagnosis. I ran the same expressions in isolated branches on the official n8n 2.34.5 and 2.35.3 Docker images. Four direct mutating methods regress to null on 2.35.3, while copy-first variants remain usable.

If you upgraded to n8n 2.35.3 and an Edit Fields expression such as:

{{ $json.data.sort() }}

suddenly evaluates to:

null

do not start by rewriting the input JSON. I reproduced the behavior locally with the official n8nio/n8n:2.34.5 and n8nio/n8n:2.35.3 Docker images. The same isolated expressions work on 2.34.5 and fail with null on 2.35.3.

The regression is broader than sort() in this test:

{{ $json.data.sort() }}
{{ $json.data.splice(0, 2) }}
{{ $json.data.fill("X", 0, 2) }}
{{ $json.data.copyWithin(0, 2, 4) }}

All four returned null on 2.35.3. reverse() still worked. Copying the array first also worked.

Do not mutate $json.data directly
Copy first, then mutate the copy

The shortest production containment I verified is:

{{ [...$json.data].sort() }}

I also tested copy-first splice(), fill() and copyWithin() on 2.35.3 rather than assuming they would behave like sort().

Why this is a version regression, not just a bad expression

n8n issue #36540, opened on August 18, 2026, reports that several mutating Array methods called directly on $json arrays started evaluating to null after an upgrade from 2.34.5 to 2.35.3. The report names the same four affected methods and also notes that reverse() and copy-first sorting still work.

I did not treat the issue report itself as enough evidence. I pulled both official Docker images and executed the same Edit Fields expressions with the same input on both versions.

The comparison environment was:

Item	Control	Regression
n8n	2.34.5	2.35.3
Docker image	`n8nio/n8n:2.34.5`	`n8nio/n8n:2.35.3`
Node.js	v24.18.0	v24.18.1
Database	default SQLite	default SQLite
Execution	n8n CLI `execute`	n8n CLI `execute`
Edit Fields	same node shape	same node shape

Every method was given its own independent branch with this input:

{
  "data": [
    "Mango",
    "Apple",
    "Kiwi",
    "Orange",
    "Blueberry",
    "Banana",
    "Peach",
    "Grape",
    "Pineapple",
    "Strawberry"
  ]
}

That isolation matters. My first combined-field workflow put several mutating expressions in one Edit Fields node. On 2.34.5 those methods really mutate the shared input array, so one field can change what a later field sees. The isolated workflow removes that source of noise and is the authoritative version matrix.

2.34.5 versus 2.35.3

The isolated results:

Expression	n8n 2.34.5	n8n 2.35.3
`$json.data.sort()`	sorted array	`null`
`$json.data.splice(0, 2)`	`['Mango','Apple']`	`null`
`$json.data.fill('X', 0, 2)`	filled array	`null`
`$json.data.copyWithin(0, 2, 4)`	mutated array	`null`
`$json.data.reverse()`	works	works
`[...$json.data].sort()`	works	works
`$json.data.slice().sort()`	works	works

Three details narrow the failure surface:

The input and node shape are unchanged; only the n8n version changes.
Not every mutating method is affected; reverse() works on 2.35.3.
Sorting itself still works when it is performed on a copied array.

So the observable boundary is not “JavaScript arrays are broken.” It is that some mutating methods called directly on arrays exposed by $json are handled differently in 2.35.3.

I am deliberately stopping there on root cause. Until upstream maintainers publish a fix or a concrete internal change, it would be speculation to claim that a particular proxy, immutability guard, expression sandbox or serialization path is the cause.

Tested workaround: copy first, then mutate

For a production workflow, I prefer the smallest reversible change first.

sort()

Before:

{{ $json.data.sort() }}

Use:

{{ [...$json.data].sort() }}

or:

{{ $json.data.slice().sort() }}

Both passed on 2.35.3.

splice()

Before:

{{ $json.data.splice(0, 2) }}

Use:

{{ [...$json.data].splice(0, 2) }}

My 2.35.3 run returned:

["Mango", "Apple"]

Remember that JavaScript splice() returns the removed elements. If your business logic needs the remaining array, changing only the regression workaround does not change that JavaScript semantic.

fill()

Before:

{{ $json.data.fill("X", 0, 2) }}

Use:

{{ [...$json.data].fill("X", 0, 2) }}

Verified 2.35.3 output:

["X", "X", "Kiwi", "Orange", "Blueberry", "Banana", "Peach", "Grape", "Pineapple", "Strawberry"]

copyWithin()

Before:

{{ $json.data.copyWithin(0, 2, 4) }}

Use:

{{ [...$json.data].copyWithin(0, 2, 4) }}

Verified 2.35.3 output:

["Kiwi", "Orange", "Kiwi", "Orange", "Blueberry", "Banana", "Peach", "Grape", "Pineapple", "Strawberry"]

These are runtime results from the same official 2.35.3 image, not untested equivalents inferred from the sort() workaround.

Why copy-first is a better expression boundary anyway

n8n expressions reference data produced by previous nodes. Calling sort(), splice(), fill() or copyWithin() directly on $json.data mixes two concerns: reading the current input and mutating the object that exposes that input.

That can make workflows harder to reason about even without this regression. The combined-field control on 2.34.5 demonstrated the risk directly: one mutating field can change the array that later expressions read.

Copy-first expressions separate the requested result from the input object:

{{ [...$json.data].sort() }}

For a simple string array, that boundary is clear. For arrays of nested objects, remember that spread syntax performs a shallow copy, so deeper mutation still requires its own design decision.

Should you downgrade to 2.34.5?

A rollback is not automatically the safest first move.

If only a handful of Edit Fields expressions are affected, replacing direct mutation with copy-first expressions is usually a smaller and more reversible production change. Search your workflows for calls such as:

.sort(
.splice(
.fill(
.copyWithin(

and focus on expressions that call them directly on $json.xxx arrays.

If a large number of workflows depend on this pattern and you cannot regression-test them quickly, a controlled rollback may be reasonable. But n8n rollback decisions also involve database migrations, other node changes, credentials and your deployment process. Back up the database and workflows and test 2.34.5 before changing production.

A practical 2.35.3 triage sequence

If your symptom matches this article:

Confirm the runtime is actually 2.35.3, including workers if you run a distributed setup.
Keep the failing expression and input as a control.
Change only the array access to a copy-first form and rerun the same item.
If the copy-first version works, check whether the expression uses sort, splice, fill or copyWithin directly on $json.
Restore the smallest failing point before refactoring the rest of the workflow.
Audit other workflows for the same direct-mutation pattern.
When upstream ships a fix, remove the workaround in a test instance first and compare outputs before changing production.

This is not the same n8n bug as yesterday's HTTP Request stream issue

XBSTACK published a separate n8n HTTP Request Raw Body / _readableState troubleshooting article yesterday. The product is the same; the search intent is not.

That issue lives in the HTTP Request Raw Body + Response Format path and exposes a stream-shaped object instead of parsed JSON.

This issue lives in Edit Fields expression evaluation and returns null for several direct $json Array mutations after the 2.35.3 upgrade.

They therefore deserve separate URLs and separate reproduction assets. For broader workflow failure patterns, see the n8n workflow error-handling guide and the Workflow hub.

Evidence boundary and upstream tracking

As of August 19, 2026, I can state the following with local runtime evidence:

Upstream issue #36540 reports the same 2.35.3 regression.
XBSTACK reproduced the version difference with official 2.34.5 and 2.35.3 Docker images.
Direct sort/splice/fill/copyWithin calls on $json.data return null on 2.35.3 in the isolated Edit Fields test.
reverse() does not show the same failure.
Copy-first versions of all four affected methods pass on 2.35.3.

I am not claiming that a specific internal commit is the root cause, and I am not predicting a fix version before upstream publishes one.

Primary references:

When upstream ships a confirmed fix, this page should be updated with the affected/fixed version matrix instead of creating another duplicate troubleshooting URL.

Canonical article and future updates:
https://www.xbstack.com/en/ai/n8n-2353-json-array-methods-return-null/?utm_source=devto&utm_medium=referral&utm_campaign=n8n_2353_array_null_regression&utm_content=article_body

Public minimal reproduction:
https://github.com/xbstack/n8n-2353-json-array-null-repro

Upstream issue:
https://github.com/n8n-io/n8n/issues/36540

DEV Community: xn

Gemini 3.8 Flash vs 3.7 Flash: Same Price, Different Agent Cost?

Gemini 3.8 Flash vs 3.7 Flash at a glance

Why can Gemini 3.8 cost more per task if the token rate is identical?

What actually improved for coding and agents?

How do you call Gemini 3.8 Flash in the API?

Which thinking level should you use?

Should existing Gemini 3.7 Flash workloads upgrade now?

Stronger candidates for immediate 3.8 evaluation

Reasons to stay on 3.7 for now

Is Gemini 3.8 Flash Cyber just a stronger 3.8 Flash?

Gemini 3.8 Flash vs 3.7 Flash: which one should you choose?

What would a real XBSTACK benchmark need to test?

FAQ

Is Gemini 3.8 Flash available through the API now?

Is Gemini 3.8 Flash more expensive than 3.7 Flash?

What is the Gemini 3.8 Flash context window?

Does Gemini 3.8 Flash support minimal thinking?

Is Gemini 3.7 Flash being discontinued?

Should I switch production traffic directly to 3.8?

Official sources

Claude Fable 5.1 vs Mythos 5.1: Same Model, Different Access Boundary

The practical decision

Pricing is only part of the story

Do not over-read vendor benchmarks

Related reading

MCP StreamableHTTPClientTransport POST Stays Pending After SSE Disconnect: Issue #2739 Re…

First, verify that your failure matches this boundary

Reproduction design: three POST response modes, no real server required

SDK 1.29.0: transport error at 4 ms, request failure at 304 ms

The current 1.30.0 release still reproduces the same lifecycle gap

The root problem is not “the timeout is too long”

Practical containment: distinguish ordinary JSON results from genuine streaming

What a real SDK fix needs to accomplish

Do not generalize this v1 result to MCP 2026-07-28 or TypeScript SDK v2

Production troubleshooting checklist

Final decision

How to Security-Check an MCP Configuration: Secrets, Shell, Remote MCP, and Permissions

1. Exposed credentials

2. Shell is not automatically a vulnerability

3. A remote MCP endpoint is a trust boundary

4. Logging and retention are separate controls

Run a browser-local static check

Pre-deployment checklist

Bottom line

Source and related reading

How to Test an MCP Server Before Production: Read-Only Inspector Preflight

What to check before production

Reading server/discover correctly

Why validate the list methods too

Why XBSTACK's public Inspector is read-only

The same probe now covers 15 public endpoints

A practical rollout order

What a read-only PASS means

Source and related reading

How to Add WebMCP to a Website: Chrome 149 Forms, Tool Schemas, and registerTool

The simplest path: expose an existing form

Richer actions: document.modelContext.registerTool

Do not register every button

Security still belongs to your application

How to verify the integration

WebMCP and llms.txt solve different problems

Recommendation

Source and related reading

How to Configure llms.txt v2: rel=alternate, describedby, and Markdown Discovery

What changed in v2

How I would deploy it on a real site

Verification checklist

What llms.txt is not

Check the whole readiness chain

Bottom line

Source and related reading

n8n Execution Stuck Running After Success: Zombie Execution When Successful Runs Are Not …

Check whether you have this specific zombie execution

Minimal reproduction: change one setting

Why this matters beyond a stale UI status

The safest workaround I can verify today

Do not use a direct database UPDATE as the generic fix

PostgreSQL versus SQLite: the evidence boundary

How to retest once a fix is released

3. Look for runner registration, not only `docker ps = Up`

Is this the same issue as the ARM64 `GLIBC_PRIVATE` Task Runner failure?

1. `store=false`