Apollo streams its logs and errors back to the caller while a service runs. When one of them fails to parse a workflow, the exception text carries the document it choked on, and that document is the user's job code. So a parse failure sends the code back out in an error string.
Sentry gets it twice over. It attaches the local variables of every stack frame by default, and on the chat services those frames hold the workflow and the preserved job bodies.
mask_secrets does not help here. It matches credential field names and key-shaped values, and job code is neither.
I noticed this while working on #446, because the naming work touches the same error paths. It is not caused by that work and it is not new.
Worth deciding whether the fix is per-line or structural. Every log line that interpolates an exception is a place this can happen, so patching the ones we know about leaves the next one to be found the same way.
Apollo streams its logs and errors back to the caller while a service runs. When one of them fails to parse a workflow, the exception text carries the document it choked on, and that document is the user's job code. So a parse failure sends the code back out in an error string.
Sentry gets it twice over. It attaches the local variables of every stack frame by default, and on the chat services those frames hold the workflow and the preserved job bodies.
mask_secretsdoes not help here. It matches credential field names and key-shaped values, and job code is neither.I noticed this while working on #446, because the naming work touches the same error paths. It is not caused by that work and it is not new.
Worth deciding whether the fix is per-line or structural. Every log line that interpolates an exception is a place this can happen, so patching the ones we know about leaves the next one to be found the same way.