Python Extension Dev: Maximum Recursion Depth Exceeded when configuring logger

[joh_elf]

Dear all,

while developing my own Python Extension using the new Pure Python Node Extensions Guide | KNIME Documentation , I stumbled upon a

RecursionError: maximum recursion depth exceeded

when trying to import a specific package.

Tracking the bug to its root, I found that configuring the logger causes this bug. Simply insert these two lines into the header of your extension-Python-file to run into the bug:

import logging.config
logging.config.dictConfig({"version": 1})

Imho this is a quite massive bug, since using logging.config.dictConfig is a quite common pattern in packages when setting up the logger.

Is there any way to avoid this bug as a work-around when importing third-party packages which configure the logger?

Full Python traceback:

File ".../knime_5.8.1/plugins/org.knime.python3.nodes_5.8.1.v202511270108/src/main/python/_node_backend_launcher.py", line 1567, in loadExtension
    importlib.import_module(extension_module)
    ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
  File ".../3.13.0/lib64/python3.13/importlib/__init__.py", line 88, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
           ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<frozen importlib._bootstrap>", line 1387, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1331, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 935, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 1022, in exec_module
  File "<frozen importlib._bootstrap>", line 488, in _call_with_frames_removed
  File ".../midas_test.py", line 32, in <module>
    logging.config.dictConfig({"version": 1})
    ~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^
  File ".../lib64/python3.13/logging/config.py", line 935, in dictConfig
    dictConfigClass(config).configure()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File ".../lib64/python3.13/logging/config.py", line 577, in configure
    _clearExistingHandlers()
    ~~~~~~~~~~~~~~~~~~~~~~^^
  File ".../python3.13/logging/config.py", line 290, in _clearExistingHandlers
    logging.shutdown(logging._handlerList[:])
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
  File ".../python3.13/logging/__init__.py", line 2243, in shutdown
    h.flush()
    ~~~~~~~^^
  File ".../python3.13/logging/__init__.py", line 1136, in flush
    self.stream.flush()
    ~~~~~~~~~~~~~~~~~^^
  File ".../python3.13/logging/__init__.py", line 1136, in flush
    self.stream.flush()
    ~~~~~~~~~~~~~~~~~^^
  File .../python3.13/logging/__init__.py", line 1136, in flush
    self.stream.flush()
    ~~~~~~~~~~~~~~~~~^^
  [Previous line repeated 978 more times]
RecursionError: maximum recursion depth exceeded

Python Version: 3.13.0

Knime AP v5.8.1.

Thanks in advance and best regards,

Johannes

[carstenhaubold]

Good catch @joh_elf!

I debugged a bit and this is due to our logging handler that derives from logging.StreamHandler even though there’s no real stream behind it. Changing that to logging.Handler fixes the issue for me. We’ll include that fix in the next KNIME release.

You can verify it on your side by modifying .../knime_5.8.1/plugins/org.knime.python3.nodes_5.8.1.v202511270108/src/main/python/_node_backend_launcher.py, search for class KnimeLogHandler(logging.StreamHandler): and change that to class KnimeLogHandler(logging.Handler):.

EDIT: but obviously, if you reconfigure logging, Python extension logs will no longer end up in KNIME’s knime.log file.

Best,
Carsten

[joh_elf]

Hi @carstenhaubold,

thanks a lot, updating the inheritance of KnimeLogHandler works.

Regarding knime.log file: Yeah, I already talked to the main-dev of the package in question if he could implement an environment variable based approach to switch off logging reconfiguration. Imho the logger configuration shouldn’t be part of a package’s import mechanism anyways to avoid overwriting configurations defined by an enclosing scope (exactly as we see it here), but that’s just my two cents…

Best regards,

Johannes