Highlight user-code frames in task log tracebacks#70294
Conversation
|
How does this look in dark mode? How different do we want these links to look like? fg.info vs fg.muted in light mode is fairly subtle. |
6c62adf to
5ce44c3
Compare
|
The pieces I really want in color are the parts that are my code (so not site-packages and not airflow itself) and the actual error message (ParserError in this case). There's so much blue on the screen that its actually hard to pick those out. I think it would be fine to put the site-packages lines just in the normal black text color. |
|
That makes sense to me, system file lines aren't important so we should reduce their highlight or remove it entirely |
In an error traceback the frame that actually failed is usually in the user's DAG code, but it sits visually indistinguishable among the framework frames from installed packages. Emphasising user-code frames and muting installed-package frames lets users find where the error originates at a glance.
5ce44c3 to
b2a35e0
Compare
|
Updated. Now library line appear in normal text color: 
Here airflow is considered 'user code' because that's a local development setup where airflow is actually installed in editable mode from source. Normally in prod environment it will be 'pip installed...' and land in site packages. |
|
On a real install. With airflow installed from a wheel: 
|
Backport successfully created: v3-3-testNote: As of Merging PRs targeted for Airflow 3.X In matter of doubt please ask in #release-management Slack channel.
|
…#70294) In an error traceback the frame that actually failed is usually in the user's DAG code, but it sits visually indistinguishable among the framework frames from installed packages. Emphasising user-code frames and muting installed-package frames lets users find where the error originates at a glance. (cherry picked from commit 4e65210) Co-authored-by: Pierre Jeambrun <pierrejbrun@gmail.com>
…#70294) In an error traceback the frame that actually failed is usually in the user's DAG code, but it sits visually indistinguishable among the framework frames from installed packages. Emphasising user-code frames and muting installed-package frames lets users find where the error originates at a glance. (cherry picked from commit 4e65210) Co-authored-by: Pierre Jeambrun <pierrejbrun@gmail.com>
#70375) In an error traceback the frame that actually failed is usually in the user's DAG code, but it sits visually indistinguishable among the framework frames from installed packages. Emphasising user-code frames and muting installed-package frames lets users find where the error originates at a glance. (cherry picked from commit 4e65210) Co-authored-by: Pierre Jeambrun <pierrejbrun@gmail.com>
4 participants
When a task fails, the frame that actually raised is almost always in the user's DAG code, but in the log traceback it looks identical to the surrounding framework frames from installed packages — so you have to scan every
File "..."line to find where your code is.This colors traceback frames by origin: frames in user code (DAG bundle, plugins, local files) stay prominent (
fg.info, bold), while frames in installed packages (site-packages/dist-packages) are muted (fg.muted). The failing user frame now stands out at a glance.Classification is a single rule — a frame is user code unless its path is under a
site-packages/dist-packagesdirectory — which is robust across bundle layouts (local folder, git,/tmp/airflow/dag_bundles/...) without hardcoding a bundle path. Adata-frame-sourceattribute (user/library) is set on each frame for testability and as a styling hook.Before
error in user code only
error in library
After
error in user code only
error in library
Was generative AI tooling used to co-author this PR?
Generated-by: Claude Code (Opus 4.8) following the guidelines