[gilesknap]

tiled's default logging config has no handler for dls_tiled.*, so the visr router's INFO messages (e.g. the cross-channel retry and give-up messages in /binned) are dropped.

This adds /deploy/log_config.yml to the image: tiled's default (tiled.server.logging_config.LOGGING_CONFIG) plus the dls_tiled loggers. Deployments select it by overriding the command with --log-config /deploy/log_config.yml; the README shows the helm args. The CI smoke test now starts the image that way.

Checked locally that with this config dls_tiled.visr INFO is emitted, and with tiled's default it is dropped.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HEadCafQcH99QcitezEp8A

Summary by CodeRabbit

• New Features
  • Added an optional logging configuration for container deployments, making Tiled and plugin informational messages visible alongside formatted server access and error logs.
• Documentation
  • Added instructions for selecting the included logging configuration when starting the container.

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: b665cd6a-dbdb-4ef7-a3ef-0e71592f3dc6

📥 Commits

Reviewing files that changed from the base of the PR and between 64cdff8 and 44fe422.

📒 Files selected for processing (4)

• .github/workflows/_container.yml
• Dockerfile
• README.md
• log_config.yml

Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.

---

📝 Walkthrough

Walkthrough

The runtime image now includes a logging configuration for tiled serve. The README explains how to use it. The container smoke test starts the server with the configuration enabled.

Changes

Container logging

Layer / File(s)	Summary
Logging configuration in the runtime image log_config.yml, Dockerfile	Adds /deploy/log_config.yml with filters, formatters, stream handlers, and INFO-level logger settings. The Dockerfile copies the configuration into the runtime image.
Serving with the logging configuration README.md, .github/workflows/_container.yml	Documents how to select the logging configuration. The container smoke test starts tiled serve config with the specified host, port, scalable mode, and configuration path.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Merge Risk: ⚪ Minimal · up to 44fe4

The image includes the logging configuration, and the documented and smoke-test commands select it consistently. No actionable merge-blocking issue is identified.

Security Architecture Review

Security architecture risk: 🔵 Low · up to 44fe4

This is a small, opt-in deployment change that makes plugin diagnostics visible in container logs. No credential or privilege expansion was identified. Log-access controls and coordinated rollback of the image and startup arguments still require deployment-specific confirmation.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — The direct exposure change concerns deployments that select this policy and readers of their container stderr logs. Scan identifiers, lengths, and failure details become visible there. Collector aggregation, tenant separation, retention, and downstream readership are not represented in the supplied deployment evidence, so the maximum downstream exposure remains unknown.

Security Findings and Attack Paths

• observed — Inspected INFO calls pass request-derived scan identifiers, numeric length dictionaries, and exception objects rather than explicit credentials or tokens. Their new visibility is established, but sensitive contents of arbitrary exception strings and unauthorized access to the resulting logs are not established. No verified disclosure attack path was identified.

Trust Boundaries and Controls

• observed — The logging policy is bundled at build time and selected by deployment startup arguments, not by an HTTP request. The binned route still declares a read:data scope check. Request-derived values can become log payloads, but this PR does not add request-controlled logging configuration or change that declared scope requirement.

Resilience and Maintainability Implications

• inferred — Processes restarted with the same image and arguments have the same bundled policy available, avoiding a new per-worker mutable configuration dependency. Whether logging-load failures terminate startup before serving, or leave partially initialized logging, cannot be determined without the upstream CLI implementation.

Hardening Proposals

• proposed — For deployments opting in, coordinate image and logging-argument rollback and confirm that log-reader access and retention are appropriate for scan identifiers and exception details. These are deployment safeguards, not findings of an unsafe production configuration.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the main change: adding a logging configuration that exposes plugin logger messages.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

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