fix(logging): emit valid JSON for messages containing quotes or newlines

[VegasNative]

What changed

Replaces the brittle string-template [formatter_json] in dashboard/logging.ini with a small JsonFormatter class (dashboard/jsonlog.py) that uses json.dumps to escape field values. Output shape is unchanged: every record still emits time, level, process_id, message, and a compound name of filename:logger:funcName:lineno.

Also adds a regression test (tests/test_jsonlog.py) asserting that a message containing both quotes and newlines round-trips through json.loads cleanly.

Why

The previous formatter interpolated %(message)s directly into a JSON-shaped template string. Any log message containing a " or a \n produced invalid JSON. This is not hypothetical: dashboard/app.py (the global exception handler around handle_exception) joins tracebacks into the message field with \n, so under the old formatter every exception log was emitted as malformed JSON. Downstream log consumers (Cloud Logging on Cloud Run, anything else parsing these as JSON) silently drop or text-fallback those records.

Using json.dumps makes the bug class disappear: every field is escaped at serialization time.

Why not python-json-logger

I considered pulling in python-json-logger, but adding a runtime dependency to a critical production system isn't worth it for ~14 lines of stdlib code. The historical JSON shape (custom keys like process_id, the compound name field) would have required a subclass to preserve regardless, so the dep would not have eliminated the code.

Blast radius

Output shape is preserved, so any consumer that worked before continues to work. The one behavioral change worth flagging: parsers that were silently dropping malformed records (every exception log) will now successfully parse them. Expect the visible volume of structured-log records to increase after this deploys, particularly in the error/warning tiers. Anyone watching log-volume dashboards or alerts on this service should be aware that the bump is the bug being fixed, not a regression.

No public-facing routes, no auth flow, no apps.yml interaction.

Cross-repo coordination

None.

Test plan

• tests/test_jsonlog.py — new test asserts a LogRecord whose message contains both " and \n produces output that round-trips through json.loads. Regression guard for the specific bug.
• tox passes locally (lint + types + tests + style).
• Manual sanity: instantiated JsonFormatter, fed it a LogRecord shaped like what app.py's exception handler produces (a string concatenated with a traceback containing newlines), confirmed valid JSON output and the historical field shape.

Caveats

• Tracebacks are still embedded in the message field as a \n-joined string, same as before. Splitting them into a separate exc_info field would be a behavior change worth doing later but is out of scope here.
• Source-location fields (filename, funcName, lineno, logger name) are still collapsed into the single compound name field. Cloud Logging would prefer them as separate top-level keys for easier filtering, but again, scope creep — a separate PR if anyone wants it.

[bheesham]

I like that this removes a hack. There are some cases it doesn't handle, but we don't make use of any of those.

[VegasNative]

Bhee — you were right. Caught it: 7 callsites in this repo use logger.exception(...), which populates record.exc_info. The original commit on this branch dropped that field, so we'd have fixed JSON validity but lost tracebacks in the output.

Pushed a follow-up commit (c23d791) that surfaces the traceback as a separate exc_info field (and stack_info when set), still through json.dumps so escaping is preserved. New regression test covers it.

Updated test plan:

• test_format_produces_valid_json_with_quotes_and_newlines — original bug
• test_format_includes_exc_info_when_record_has_traceback — this bug

Affected callsites in this repo (all now keep their tracebacks in the output):

• dashboard/op/yaml_loader.py (YAML load failures)
• dashboard/app.py (TokenError handler)
• dashboard/vanity.py (route registration errors)
• dashboard/models/tile.py (3 sites — etag, config fetch, config load)
• dashboard/models/user.py (userinfo fallback path)

Cross-org search: no other mozilla-iam or mozilla-it repo copies this [formatter_json] template or parses these log fields, so no downstream impact to coordinate.

[VegasNative]

Both asymmetries addressed in 1644ab7:

• stack_info dropped from the impl. Before doing this I checked three places for any caller: nothing in this repo, nothing in the runtime deps (Flask, gunicorn, gevent, redis, flask_pyoidc, urllib3, requests, josepy, etc.), nothing in the rest of mozilla-iam Python code. So removing it doesn't lose any in-use diagnostic path. If a stack_info=True caller ever shows up, the handling + test can land with it.
• Args path now actually exercised by test 1. Switched from args=() with a literal message to a %s-formatted msg with real args, so the test now covers record.getMessage()'s % interpolation alongside the JSON escaping.