N8n-node - Get (not Get Many) Execution - Quirk with expression in Execution ID field

Why does the n8n-node - Execution - Get function behave differently depending upon how the Execution ID value is supplied?

(The point of this is to, maybe, find out how to avoid this kind of thing in general. However, this might just be a bug in the API… in which case, maybe this all amounts to curiosity. Obviously, since there is workaround, it’s not anything that needs a solution.)

  1. Execution ID = expression referencing a value from a previous set node (string) - works fine / returns 1 matching item as expected
  2. Execution ID = expression referencing a value from a previous set node (number) - works fine / returns 1 matching item as expected
  3. Execution ID = expression referencing $execution.id directly - behaves more like Get Many - ALL EXECUTIONS RETURNED (but as 1 JSON item).
    • The expectation is that this should return only 1 item, matching the Execution ID value.
    • Is the Execution ID value ignored for some reason in this case?
    • Is the data type of $execution.id wrong for the Execution ID value?
    • Is the value being interpreted as a wildcard somehow?
  4. expression with bogus executionId - works as expected / returns “not found” error.

Information on your n8n setup

  • n8n version: 1.62.5
  • Database (default: SQLite): postgres 16
  • n8n EXECUTIONS_PROCESS setting (default: own, main): own, main
  • Running n8n via (Docker, npm, n8n cloud, desktop app): Docker
  • Operating system: Linux

Hi @hubschrauber

Thanks for reporting this! I tried to debug it and my theory is that execution.id could be undefined and so it defaults to return all…

I think @Jon wanted to look at it - linking you up here

$execution.id is one of those “filled at execution time” variables. It would surprise me if it is undefined since it is clearly defined/available in the Set node. Possibly it is not “in scope” when the n8n node references it? The only difference between the /api/v1/executions call for Get many and Get (one) would be the presence of the {id} path parameter. If the n8n node Operation parameter is set to Get (not Get many), and the value for Execution ID is undefined/missing/null, I think it should result in an error, not continue-anyway-with-weird behavior.

One other theory I had was that the execution itself had not yet been committed to the DB table when the n8n node calls the get API endpoint (i.e. race condition). However, that should result in “not found” instead of a full list of all executions.

I tried invoking the API directly from postman to see if I could guess the circumstances (e.g including an ending slash but no id /api/v1/executions/), but nothing I tried matched the behavior when the n8n node (axios, etc.) is the client (not postman). Betting it is a combination of contextual things in the n8n node code itself.

Good luck.