`NoneType` object has no attribute `access_key`

[jonded94]

I'm using a setup similar to what is described in #21 (comment).

Trying to interact with parquet data (the rest such as image files work fine) currently leads to error messages. In my custom logger setup, I could retrieve information about where this exception is raised:

{"timestamp": "2026-03-26 13:52:00,801", "level": "ERROR", "name": "smoosense.handlers.query", "message": "Query execution failed: 'NoneType' object has no attribute 'access_key'", "path": "/opt/uv-tools/gunicorn/lib/python3.14/site-packages/smoosense/handlers/query.py", "line": 44, "pid": 9}

EDIT: I just realized that this error appears even with a S3Client set. For reference, this is my app.py:

import logging
import json
import sys

import boto3
from smoosense.app import SmooSenseApp


class JSONFormatter(logging.Formatter):
    def format(self, record: logging.LogRecord) -> str:
        return json.dumps(
            {
                "timestamp": self.formatTime(record),
                "level": record.levelname,
                "name": record.name,
                "message": record.getMessage(),
                "path": record.pathname,
                "line": record.lineno,
                "pid": record.process,
            }
        )


def configure_logging() -> None:
    handler = logging.StreamHandler(sys.stderr)
    handler.setFormatter(JSONFormatter())
    logging.root.handlers = [handler]
    logging.root.setLevel(logging.INFO)


configure_logging()

session = boto3.Session()
s3_client = session.client("s3")

app = SmooSenseApp(s3_client=s3_client).create_app()

This is installed in a Dockerfile such as:

COPY app.py gunicorn.conf.py /app/

RUN useradd -m -s /bin/bash -u 1000 linguee

USER 1000

EXPOSE 8000

CMD ["gunicorn", "app:app", "--config", "gunicorn.conf.py"]

[jonded94]

I believe this error comes from accessing a variable which can be None here:

smoosense/smoosense-py/smoosense/utils/duckdb_connections.py

Line 43 in a92135a

aws_key = credentials.access_key

Some thoughts:

• I see that you're running mypy here. In our codebases, we always run mypy --strict because the default mypy behavior is just way too permissive and allows errors such as these.
  • How about trying mypy --strict?
  • How about pyrefly / pyright? They are actually even more correct than mypy and can catch additional errors sometimes (but also introduce false positives sadly).
• The error message here is pretty vague and doesn't really help at all TBH. How about being way more explicit here:
  • Instead of logging.error([msg]), how about logging.exception([msg]) (which automatically adds exception info) or the explicit exc_info parameter?
  • Instead of just printing error=str(e), how about including way more info, such as the whole exception trace (or at least certain levels from it)?

This is a Claude-vibed version of a fix of this issue (I wanted you to have a look before I vibe-submit a PR 😅):

Here's the summary of the issue and fix:

Root cause (duckdb_connections.py:41-44): The maker() closure inside duckdb_connection_using_s3 unconditionally does:

credentials = s3_client._request_signer._credentials
aws_key = credentials.access_key # 💥 NoneType has no attribute 'access_key'

When boto3.Session().client("s3") is created in a container without AWS credentials available (no env vars, no IAM role, no ~/.aws/credentials), _credentials resolves to None. The code never checks for this.

Two fixes applied:

1. None guard — if _credentials is None, log a warning and fall back to a default (non-S3) DuckDB connection. Local parquet queries will still work fine.
2. get_frozen_credentials() — the old code accessed .access_key / .secret_key / .token directly on the raw credentials object. This doesn't properly handle RefreshableCredentials or DeferredRefreshableCredentials (common with IRSA / EKS Pod
   Identity / instance profiles). Using get_frozen_credentials() returns a properly resolved snapshot, which also fixes potential issues the reporter mentioned ("this error appears even with a S3Client set" — likely deferred credentials that
   hadn't resolved yet).

bugfix.patch