Wire LOG_LEVEL config into logging.basicConfig

[Gutts-n]

Why

Investigating why ckan:resource-update-stress (a NESO UAT performance test)
consistently gets a 404 from datastore_search for resources that genuinely
have data in BigQuery. Traced the 404 to backend.py's _read_schema catching
google.api_core.exceptions.NotFound from BigQuery's own tables.get call —
but the service has no way to show what the real underlying error is,
because LOG_LEVEL was never actually wired up.

Config already declares LOG_LEVEL (core/config.py) and this repo's own
CLAUDE.md roadmap lists "the existing log.debug lines in auth + error
handlers + the CKAN provider light up under LOG_LEVEL=DEBUG" as a stated
goal — but main.py calls logging.basicConfig(level=logging.INFO, ...) with
a hardcoded literal, before the config is even read. Setting the
LOG_LEVEL env var on a deployment currently does nothing.

What changed

datastore/main.py: logging.basicConfig now reads get_config().LOG_LEVEL
instead of a hardcoded logging.INFO.

What was verified

• Ran the full test suite before and after this change
  (pytest tests/ -k "not integration"). Two pre-existing failures in
  tests/test_datastore_dump.py (parquet export column casting) exist
  identically on main without this change — confirmed by stashing the
  diff and re-running each one individually. Everything else passes
  (494 passed, same as baseline).
• Confirmed Config.LOG_LEVEL is a Literal["DEBUG","INFO","WARNING","ERROR","CRITICAL"]
  field with a default of "INFO", so this change is a no-op for any
  deployment that hasn't set LOG_LEVEL explicitly — behavior only
  changes when the env var is actually set.

Context for the resource-update-stress investigation

Separate from this PR, but the reason it exists: reproduced live with a
fresh sysadmin CKAN token that datastore_authorize succeeds (200,
correct resource/package) for a resource that then immediately 404s on
datastore_search, and that this persists for days (ruling out an
ingestion timing race). The only place that 404 can originate in this
codebase is backend.py's _read_schema catching a real NotFound from
BigQuery's tables.get, even though the same table is trivially queryable
with the same read-only service account from a fresh script. This PR
doesn't fix that bug — it unblocks getting a real error message out of
the service the next time it happens, instead of the generic wrapped 404.

Deployment

Whatever pipeline builds and deploys this service's image needs to pick
up this change before LOG_LEVEL=DEBUG on a running deployment will
actually do anything.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: 512ff19e-1b4c-4a8d-a6bf-be9c01e953ad

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}