Job code reaches Sentry by three routes that include_local_variables does not cover

[elias-ba]

Job code and workflow YAML can reach Sentry, and two of the routes also reach the client over SSE. All of this predates #446; the branch for that issue closes the frame-locals route and nothing else, so I am splitting the rest out rather than growing that PR further.

The frame-locals route is closed on the #446 branch by setting include_local_variables=False in services/entry.py. That one covers stack frames, including the __cause__/__context__ chain, so a handler that re-raises no longer ships the original frame. What it does not cover is anything explicitly attached to an event or logged as text.

Three routes remain. The first is sentry_sdk.set_context("request_data", ...) at services/workflow_chat/workflow_chat.py:1104 and services/job_chat/job_chat.py:748. The payload goes in whole, mask_secrets matches key-shaped values and has no notion of job code, and the context sits on the isolation scope, so one chat request attaches its workflow to every later event in that process. The second is code_edit_context.llm_edit_answer at services/job_chat/job_chat.py:612, which is the model's code answer. The third is LoggingIntegration, which is a default integration that auto_enabling_integrations=False does not switch off, so it picks up the full-prompt log at services/job_chat/prompt.py:536. The set_context and logging routes also reach the caller, because the bridge forwards matching log lines as SSE events (platform/src/bridge.ts:18).

Worth saying out loud in the same place: when a user opts into Langfuse, only the three main() functions pass capture_input=False, so every inner @observe span ships job bodies. That is consent rather than a leak, but nobody reading the code today would know it works that way.

I want to fix these together rather than piecemeal, because the pattern is the same each time and we have now declared this closed six times on the #446 branch alone. The shape of the fix is a single scrubber that knows what job code looks like, applied at before_send rather than at each call site, plus dropping the payload from set_context entirely and logging a digest instead of a prompt.

I will pick this up after #446 merges. Flagging it now so it does not get lost in that review thread.

[elias-ba]

Update from the #446 round-ten review: the branch now closes more of this than the original write-up assumed, so the remaining scope is narrower.

Closed on #446: include_local_variables=False, the eight logger.exception calls on the job-code path, and every site that interpolated an exception into a log line or an ApolloError message across global_chat, subagent_caller, planner, router, workflow_chat and job_chat. The sharp one was job_chat.apply_code_edits, which put the model's search and replace strings — lifted straight out of the user's job body — onto a line the bridge forwards as SSE. There is now a source-scan guard over those six modules plus yaml_utils (services/global_chat/tests/unit/test_error_logging.py") that catches logger.exception, f-strings, %-args, concatenation, intermediate variables and str(e)in a payload; opting out needs an inline# safe-error-text:` marker with a reason, and a test asserts the reason is there.

Still open here, unchanged: the set_context("request_data", ...) calls in workflow_chat and job_chat, code_edit_context.llm_edit_answer, and LoggingIntegration picking up the full-prompt log at job_chat/prompt.py:536. Plus the Langfuse capture_input point.

One correction to my original text: I said the frame-locals route was the only one #446 touched. That is no longer true.

[elias-ba]

Partially fixed on #446 rather than deferred, because that branch was raising the event volume on these contexts and it would have been irresponsible to add load to a leaking channel.

Added drop_code alongside mask_secrets in langfuse_util: it withholds the value of every code-bearing field (existing_yaml, workflow_yaml, expression, code, old_code, new_code, body, history, content, text_answer, llm_text_answer, llm_edit_answer, suggested_code) and keeps the field name and size, so an operator can still tell one failure from another. Applied at both set_context("request_data", ...) sites and at code_edit_context. prompt.py no longer logs the whole prompt at INFO — that was becoming a Sentry breadcrumb as well as an SSE event.

I also demoted the never-restored half of _report_claims from capture_message to an INFO log. It fires on every ordinary step deletion, so it would have turned a rare event into a routine one.

Still open here: LoggingIntegration as a default integration, and the Langfuse capture_input point. Both need the before_send scrubber from #656, which is where I would put the remaining work.