n8n - ✅(Solved) Fix Python native Code node: datetime.strptime() fails in task runner sandbox with "'mappingproxy' object has no attribute 'import'" [1 pull requests, 2 comments, 3 participants]

Q: Expected behavior

`datetime.strptime()` should work in Python native Code nodes the same way other standard-library datetime parsing methods do.

n8n2026-04-23 16:17:36

ON THIS PAGE

Recommended Tools

×6

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

GitHub issue graph ai analysis

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

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

GitHub issue URL

Helpful · Quick feedback

GitHub stats

n8n-io/n8n#29010•Fetched 2026-04-24 06:12:44

View on GitHub

Comments

Participants

Timeline

Reactions

Author

Participants

Timeline (top)

commented ×2cross-referenced ×1labeled ×1mentioned ×1

Error Message

Error: 'mappingproxy' object has no attribute '__import__'
    at throwExecutionError (.../nodes/Code/throw-execution-error.ts:11:9)
    at PythonTaskRunnerSandbox.runUsingIncomingItems (.../nodes/Code/PythonTaskRunnerSandbox.ts:69:30)
    at processTicksAndRejections (node:internal/process/task_queues:104:5)
    at ExecuteContext.execute (.../nodes/Code/Code.node.ts:201:12)

From the Python runner traceback:

Traceback (most recent call last):
  File "/opt/runners/task-runner-python/.venv/lib/python3.13/site-packages/src/task_executor.py", line 257, in _per_item
    exec(compiled_code, globals)
  File "<per_item_task_execution>", line 6, in <module>
  File "<per_item_task_execution>", line 3, in _user_function
AttributeError: 'mappingproxy' object has no attribute '__import__'

Root Cause

This appears to be caused by the Python task runner sandbox, not by the workflow data itself.

Fix Action

Workaround

Using datetime.fromisoformat(...) instead of datetime.strptime(...) works for ISO-like timestamps such as:

from datetime import datetime

dt = datetime.fromisoformat("2026-04-23T16:04:28+0000")

PR fix notes

PR #29021: fix(task-runner-python): allow strptime imports

Repository: n8n-io/n8n
Author: corazzione
State: open | merged: False
Link: https://github.com/n8n-io/n8n/pull/29021

Description (problem / solution / changelog)

Summary

stop wrapping filtered Python builtins in MappingProxyType
keep the safe __import__ override in place while restoring stdlib compatibility for datetime.strptime()
add regression coverage for the strptime() per-item execution path and update the builtins unit expectation

Root cause

The Python task runner injects __builtins__ as a MappingProxyType. That breaks stdlib code paths used by datetime.strptime(), which expect builtins to expose import machinery the same way normal exec globals do. In practice this crashes with "mappingproxy object has no attribute __import__" before user code can complete.

Changes

return a plain filtered builtins dict from _filter_builtins()
preserve the sandboxed safe import function on __import__
add an integration regression test for datetime.strptime() in per-item mode
update the builtins unit test to match the new return type

Validation

git diff --check
local Python reproduction outside the runner: MappingProxyType(dict(__builtins__)) reproduces the reported __import__ failure, while dict(__builtins__) allows the same datetime.strptime() call to succeed
attempted: uv run pytest tests/unit/test_task_executor.py -k filter_builtins
attempted: uv run pytest tests/integration/test_execution.py -k datetime_strptime_works

Notes

The uv run pytest commands are blocked in this environment because the task runner package assumes Unix process primitives (ForkServerProcess) and the available environment here is Windows, so the full runner test suite could not be completed locally.

Fixes #29010

Changed files

packages/@n8n/task-runner-python/src/task_executor.py (modified, +1/-1)
packages/@n8n/task-runner-python/tests/integration/test_execution.py (modified, +21/-0)
packages/@n8n/task-runner-python/tests/unit/test_task_executor.py (modified, +2/-3)

Code Example

'mappingproxy' object has no attribute '__import__'

---

from datetime import datetime

return {
  "ok": True
}

---

from datetime import datetime

datetime.strptime("2026-04-23T16:04:28+0000", "%Y-%m-%dT%H:%M:%S%z")

return {
  "ok": True
}

---

Error: 'mappingproxy' object has no attribute '__import__'
    at throwExecutionError (.../nodes/Code/throw-execution-error.ts:11:9)
    at PythonTaskRunnerSandbox.runUsingIncomingItems (.../nodes/Code/PythonTaskRunnerSandbox.ts:69:30)
    at processTicksAndRejections (node:internal/process/task_queues:104:5)
    at ExecuteContext.execute (.../nodes/Code/Code.node.ts:201:12)

---

Traceback (most recent call last):
  File "/opt/runners/task-runner-python/.venv/lib/python3.13/site-packages/src/task_executor.py", line 257, in _per_item
    exec(compiled_code, globals)
  File "<per_item_task_execution>", line 6, in <module>
  File "<per_item_task_execution>", line 3, in _user_function
AttributeError: 'mappingproxy' object has no attribute '__import__'

---

'mappingproxy' object has no attribute '__import__'

---

from datetime import datetime

dt = datetime.fromisoformat("2026-04-23T16:04:28+0000")

---

from datetime import datetime

return {
  "ok": True
}

---

from datetime import datetime

datetime.strptime("2026-04-23T16:04:28+0000", "%Y-%m-%dT%H:%M:%S%z")

return {
  "ok": True
}

RAW_BUFFERClick to expand / collapse

Bug Description

Bug description

When using a Python native Code node, calling datetime.strptime() fails with:

'mappingproxy' object has no attribute '__import__'

This appears to be caused by the Python task runner sandbox, not by the workflow data itself.

To reproduce

Create a workflow with a Python native Code node.

This works:

from datetime import datetime

return {
  "ok": True
}

This fails:

from datetime import datetime

datetime.strptime("2026-04-23T16:04:28+0000", "%Y-%m-%dT%H:%M:%S%z")

return {
  "ok": True
}

I was also able to reproduce it directly inside the task runner environment:

from datetime import datetime works
datetime.strptime(...) throws the same error

Error

Error: 'mappingproxy' object has no attribute '__import__'
    at throwExecutionError (.../nodes/Code/throw-execution-error.ts:11:9)
    at PythonTaskRunnerSandbox.runUsingIncomingItems (.../nodes/Code/PythonTaskRunnerSandbox.ts:69:30)
    at processTicksAndRejections (node:internal/process/task_queues:104:5)
    at ExecuteContext.execute (.../nodes/Code/Code.node.ts:201:12)

From the Python runner traceback:

Traceback (most recent call last):
  File "/opt/runners/task-runner-python/.venv/lib/python3.13/site-packages/src/task_executor.py", line 257, in _per_item
    exec(compiled_code, globals)
  File "<per_item_task_execution>", line 6, in <module>
  File "<per_item_task_execution>", line 3, in _user_function
AttributeError: 'mappingproxy' object has no attribute '__import__'

Expected behavior

datetime.strptime() should work in Python native Code nodes the same way other standard-library datetime parsing methods do.

Actual behavior

datetime.strptime() crashes inside the Python task runner sandbox with:

'mappingproxy' object has no attribute '__import__'

Environment

n8n version: 2.17.6
Deployment: Self-hosted
Execution mode: queue
Python runner: external task runners
Custom runner image based on: n8nio/runners:2.17.6
Python version inside runner: 3.13.13

Additional notes

I tested these combinations:

runOnceForAllItems + from datetime import datetime => works
runOnceForEachItem + from datetime import datetime => works
runOnceForEachItem + datetime.strptime(...) => fails
datetime.fromisoformat(...) works as a workaround for the same timestamp format

So the issue seems specifically related to datetime.strptime() in the sandboxed Python runner, likely due to an internal import path interacting badly with the sandboxed __builtins__.

Workaround

Using datetime.fromisoformat(...) instead of datetime.strptime(...) works for ISO-like timestamps such as:

from datetime import datetime

dt = datetime.fromisoformat("2026-04-23T16:04:28+0000")

To Reproduce

Create a workflow with a Python native Code node.

This works:

from datetime import datetime

return {
  "ok": True
}

This fails:

from datetime import datetime

datetime.strptime("2026-04-23T16:04:28+0000", "%Y-%m-%dT%H:%M:%S%z")

return {
  "ok": True
}

I was also able to reproduce it directly inside the task runner environment:

from datetime import datetime works
datetime.strptime(...) throws the same error

Expected behavior

datetime.strptime() should work in Python native Code nodes the same way other standard-library datetime parsing methods do.

Debug Info

Debug info

core

n8nVersion: 2.17.6
platform: docker (self-hosted)
nodeJsVersion: 24.14.1
nodeEnv: production
database: postgres
executionMode: scaling (single-main)
concurrency: -1
license: enterprise (production)
consumerId: b048c93d-46e8-48c0-9876-8e56904f8f06

storage

success: all
error: all
progress: false
manual: true
binaryMode: database

pruning

enabled: true
maxAge: 168 hours
maxCount: 50000 executions

client

userAgent: mozilla/5.0 (macintosh; intel mac os x 10_15_7) applewebkit/537.36 (khtml, like gecko) chrome/147.0.0.0 safari/537.36
isTouchDevice: false

Generated at: 2026-04-23T16:16:28.162Z

Operating System

Ubuntu 20.04.6 LTS

n8n Version

2.17.6

Node.js Version

24.14.1

Database

PostgreSQL

Execution mode

queue

Hosting

self hosted

extent analysis

TL;DR

Use datetime.fromisoformat() instead of datetime.strptime() for parsing ISO-like timestamps in Python native Code nodes.

Guidance

The issue seems to be related to the sandboxed Python runner and datetime.strptime(), so using datetime.fromisoformat() is a viable workaround.
Verify that the input timestamp is in ISO format before using datetime.fromisoformat().
If the timestamp format varies, consider adding error handling to catch and handle any potential parsing errors.
The datetime.fromisoformat() method is specifically designed for parsing ISO 8601 timestamps, making it a suitable replacement for datetime.strptime() in this context.

Example

from datetime import datetime

dt = datetime.fromisoformat("2026-04-23T16:04:28+0000")

Notes

This workaround assumes that the input timestamps are in ISO format. If the format varies, additional parsing or validation may be necessary.

Recommendation

Apply the workaround using datetime.fromisoformat() instead of datetime.strptime() for parsing ISO-like timestamps, as it is a more straightforward and reliable solution in this context.

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

FAQ

Expected behavior

datetime.strptime() should work in Python native Code nodes the same way other standard-library datetime parsing methods do.

#runtime error #dependency conflict #environment setup #docker error #permission error

Still need to ship something?

×6

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

n8n - ✅(Solved) Fix Python native Code node: datetime.strptime() fails in task runner sandbox with "'mappingproxy' object has no attribute '__import__'" [1 pull requests, 2 comments, 3 participants]

Recommended Tools

GitHub issue graph ai analysis

Error Message

Root Cause

Fix Action

Workaround

PR fix notes

PR #29021: fix(task-runner-python): allow strptime imports

Description (problem / solution / changelog)

Summary

Root cause

Changes

Validation

Notes

Changed files

Code Example

Bug Description

Bug description

To reproduce

Error

Expected behavior

Actual behavior

Environment

Additional notes

Workaround

To Reproduce

Expected behavior

Debug Info

Debug info

core

storage

pruning

client

Operating System

n8n Version

Node.js Version

Database

Execution mode

Hosting

extent analysis

TL;DR

Guidance

Example

Notes

Recommendation

FAQ

Expected behavior

Still need to ship something?

RELATED_DISCOVERY

TRENDING

n8n - ✅(Solved) Fix Python native Code node: datetime.strptime() fails in task runner sandbox with "'mappingproxy' object has no attribute 'import'" [1 pull requests, 2 comments, 3 participants]