Do you need to file an issue?
Describe the bug
AzureBlobStorage.set() logs its failure with a format string that has two
%s placeholders but supplies one argument:
https://github.com/microsoft/graphrag/blob/main/packages/graphrag-storage/graphrag_storage/azure_blob_storage.py#L195
except Exception:
logger.exception("Error setting key %s: %s", key)
logging raises TypeError: not enough arguments for format string while
rendering the record, catches it internally, drops the record, and writes
--- Logging error --- plus a traceback to stderr instead.
The net effect is that when a blob write fails, the diagnostic that was written
specifically for that case never reaches the configured log handlers — exactly
the moment the log is needed. The exception is swallowed by the bare except,
so the failed write is otherwise silent.
Every sibling handler uses one placeholder and one argument, e.g. lines 176 and
251 in the same file (logger.warning("Error getting key %s", key)) and the
four handlers in azure_cosmos_storage.py
(logger.exception("Error reading item %s", namespaced) etc.). This one call
site is the only one with a stray : %s.
Steps to reproduce
Any failing blob write reaches it; the call shape reproduces standalone:
import logging
logging.basicConfig()
log = logging.getLogger("repro")
try:
raise ValueError("blob upload failed")
except Exception:
log.exception("Error setting key %s: %s", "output/entities.parquet")
Observed — no log record is emitted, and stderr gets:
--- Logging error ---
Traceback (most recent call last):
File ".../logging/__init__.py", line 1160, in emit
msg = self.format(record)
...
TypeError: not enough arguments for format string
Dropping the extra : %s emits the intended record (with the traceback that
logger.exception appends anyway).
Expected Behavior
The failure is logged through the normal handlers, like every sibling handler
in the storage package.
GraphRAG Config Used
Not config-dependent — any configuration using the Azure Blob storage backend.
Logs and screenshots
Included above.
Additional Information
- GraphRAG Version: main (
packages/graphrag-storage)
- Python Version: any supported version (stdlib
logging behaviour)
Happy to send the one-line PR.
🤖 Generated with Claude Code
Do you need to file an issue?
Describe the bug
AzureBlobStorage.set()logs its failure with a format string that has two%splaceholders but supplies one argument:https://github.com/microsoft/graphrag/blob/main/packages/graphrag-storage/graphrag_storage/azure_blob_storage.py#L195
loggingraisesTypeError: not enough arguments for format stringwhilerendering the record, catches it internally, drops the record, and writes
--- Logging error ---plus a traceback to stderr instead.The net effect is that when a blob write fails, the diagnostic that was written
specifically for that case never reaches the configured log handlers — exactly
the moment the log is needed. The exception is swallowed by the bare
except,so the failed write is otherwise silent.
Every sibling handler uses one placeholder and one argument, e.g. lines 176 and
251 in the same file (
logger.warning("Error getting key %s", key)) and thefour handlers in
azure_cosmos_storage.py(
logger.exception("Error reading item %s", namespaced)etc.). This one callsite is the only one with a stray
: %s.Steps to reproduce
Any failing blob write reaches it; the call shape reproduces standalone:
Observed — no log record is emitted, and stderr gets:
Dropping the extra
: %semits the intended record (with the traceback thatlogger.exceptionappends anyway).Expected Behavior
The failure is logged through the normal handlers, like every sibling handler
in the storage package.
GraphRAG Config Used
Not config-dependent — any configuration using the Azure Blob storage backend.
Logs and screenshots
Included above.
Additional Information
packages/graphrag-storage)loggingbehaviour)Happy to send the one-line PR.
🤖 Generated with Claude Code