Repository navigation
fix(logging): correlate safe server diagnostics (ENG-3579) - #5
Merged
Merged
Conversation
Refs: ENG-3579
Refs: ENG-3579
This was referenced Oct 21, 2026
Merged
Merged
lucas-koontz
marked this pull request as ready for review
October 21, 2026 07:35
mindsdb-devops
approved these changes
Oct 21, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
User story
As an on-call engineer
I want quiet, correlated diagnostics
So that I can diagnose failures without exposing customer data
Why this matters
Operators can receive raw database and provider values through independent console, file and telemetry handlers. These diagnostic destinations now use a safe JSON envelope at WARNING. Final HTTP failures retain request correlation across the WSGI bridge.
Visual review
A deployed before/after capture remains a rollout gate for this runtime. Local regression and container evidence below establish behavior, not a production volume reduction.
Acceptance criteria
/api/util/pingand the Docker/api/statushealth probe stay quiet even with access logging enabled; failed probes and non-probe methods remain visible.docs/structured-logging.md.How to test
Notes for the reviewer
snowflake-sqlalchemy==1.9.0imports an ORM interface removed in SQLAlchemy 2.1. The bound lives in the shared application requirements so installation and the requirements checker agree. Hosted full-suite validation and live collector export remain separate checks.Current review validation
ORMSelectCompileStatefailure with SQLAlchemy 2.1.5; the shared<2.1bound resolves 2.0.55 and restores the real dialect import./api/statusemitted access records; both GET/HEAD probe paths are quiet after the fix, while 503 and POST records remain visible./api/statusand/api/util/pingunder access=all, visible WARNING/404, request-ID echo and private-query exclusion.075c4e888, clearing the previous Snowflake import failure. Deployment jobs were skipped.Earlier validation
These results precede the dependency/probe follow-up:
snowflake.sqlalchemywith SQLAlchemy 2.1. The dependency fix and local verification are described above; live OTLP collector export remains unverified.Ships with
mindsdb/anton#621, mindsdb/cowork-server#741, mindsdb/cowork#1263, mindsdb/mindshub#12504.
Merge/release order: mindsdb/anton#621, then mindsdb/cowork-server#741, then mindsdb/cowork#1263. #5 can proceed independently. Update reviewed release pins and rebuild mindsdb/mindshub#12504 last.