Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(ui): handle trace not being available without exceptions #33427

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

Skn0tt
Copy link
Member

@Skn0tt Skn0tt commented Nov 4, 2024

The control flow for loading live traces is currently based on exceptions, and it's hard to follow. It's expected that the live trace only becomes available after a couple retries, but the code doesn't reflect that.

This PR adds some handling for 404s so we represent the "trace not yet available" state with 404 responses instead of
errors. It also renames the counter state to rerender to make the intent clearer.

Console before this change:

Screenshot 2024-11-04 at 16 01 58

Console after this change:

Screenshot 2024-11-04 at 16 02 46

Closes #33339.

@Skn0tt Skn0tt requested a review from dgozman November 4, 2024 15:02
@Skn0tt Skn0tt self-assigned this Nov 4, 2024

This comment has been minimized.

This comment has been minimized.

Copy link
Contributor

github-actions bot commented Nov 4, 2024

Test results for "tests 1"

1 failed
❌ [playwright-test] › playwright.trace.spec.ts:137:5 › should not throw with trace: on-first-retry and two retries in the same worker @macos-latest-node18-1

36743 passed, 678 skipped
✔️✔️✔️

Merge workflow run.

@@ -54,6 +54,8 @@ async function loadTrace(traceUrl: string, traceFileName: string | null, clientI
const backend = traceUrl.endsWith('json') ? new FetchTraceModelBackend(traceUrl) : new ZipTraceModelBackend(traceUrl, fetchProgress);
await traceModel.load(backend, unzipProgress);
} catch (error: any) {
if (error?.message === 'trace not found')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like you are mostly addressing the malformed (empty) JSON in live mode. Should we check that at parse time and return empty trac instead?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a nice idea as well, but I think it'd be more complex. Just one example, we're treating empty traces as an error while parsing:

if (!ordinals.length)
throw new Error('Cannot find .trace file');

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[internal]: hide trace viewer error when fetching trace JSON
2 participants