n8n_get_execution does not respond

[Matteo-Rossini]

I tried to max out all the timeout and response size variables but nothing has worked. I am sure it is due to the big amount of data (failed workflows respond correctly), but even waiting 1 hour does not resolve this.
I am using Antigravity.

[czlonkowski]

Hi @Matteo-Rossini , please, share some mode details - your setup, versions, logs etc.

[Matteo-Rossini]

Hi @czlonkowski!
Antigravity is running version 2.0.11, n8n is running version 11.12.1, and n8n-mcp is running version 2.57.1.
Antigravity is in my client pc while boh n8n and n8n-mcp are on a Windows Server 2019, so i am using https comunication.
Over the past few days of debugging, I changed the PATH variables and increased the timeout values. After those changes, everything seemed to be working correctly for a while.

However, I am still seeing Antigravity get stuck on n8n_test_workflow on random occasions. It has been stuck for around 30 minutes, even though the actual n8n workflow completed successfully in about 12 minutes.
The only clue i have about it are below, it looks like session hasn't been renovated
automatically.
[2026-06-09T06:16:44.072Z] [n8n-mcp] [DEBUG] POST /mcp authenticated {
ip: 'client',
userAgent: 'node',
contentType: 'application/json',
contentLength: '398',
headers: {
host: 'server:3000',
connection: 'keep-alive',
'mcp-session-id': '73fab7f9-97ab-4560-a5ec-9d8cf2391755',
authorization: '[REDACTED]',
'content-type': 'application/json',
accept: 'application/json, text/event-stream',
'accept-language': '*',
'sec-fetch-mode': 'cors',
'user-agent': 'node',
'accept-encoding': 'gzip, deflate',
'content-length': '398'
},
body: { jsonrpc: '2.0', method: 'tools/call', id: 3, hasParams: true },
activeSessions: 0
}
[2026-06-09T06:16:44.073Z] [n8n-mcp] [INFO] POST /mcp request completed - checking response status {
responseHeadersSent: true,
responseStatusCode: 404,
responseFinished: true
}

[czlonkowski]

Thanks for the detailed follow-up, @Matteo-Rossini — the log snippet is really helpful. Looking at it, there are actually two separate concerns tangled together here, and they're at different stages:

1. Large n8n_get_execution payloads — this is largely mitigated in current versions. handleGetExecution now supports mode = preview / summary / filtered / full / error, and the legacy includeData: true path is mapped to a capped summary (2 items per node) instead of dumping the full data and blowing past token limits (see src/mcp/handlers-n8n-manager.ts). You're on 2.57.1, which has this. Could you retry the heavy execution with an explicit n8n_get_execution({ id: '<id>', mode: 'preview' }) and let us know if that part still misbehaves? preview analyzes structure without returning the bulk data.

2. Session churn on n8n_test_workflow — this is the real signal in your log. The request comes in with a valid mcp-session-id, but activeSessions: 0 and the server returns 404, meaning the streamable session was dropped server-side before the long-running call completed. That's the keepalive gap, not a data-size issue. Open PR #595 ("keep streamable sessions alive on GET") targets exactly this — it refreshes the session access time on GET /mcp so the session doesn't churn during long waits. It's still open (currently has merge conflicts and is pending review, so not merged yet), but it addresses precisely the activeSessions 0 -> 404 pattern you're seeing.

Keeping this open to track the session-keepalive side. If the mode: 'preview' retest clears up the large-payload concern for you, that would help us confirm #1 is fully resolved and focus this thread on the session lifecycle. Thanks again for the legwork on this.

[geraistec]

1+