fix(trace-viewer): Keep showing source when test is scheduled

[cpAdm]

Currently after 500ms the trace file would be fetched (loadSingleTraceFile), this however fails since the test is still (likely) to be scheduled at that point in time. This causes the model to be reset to a new empty one. Since there now is a model, useSources will instead try to fetch the source file from sha1/src, but with an empty trace URL. The SW doesn't like this empty trace URL and throws an error Error: File not found, and returns status code 505 (not 400, so it's not retried via file endpoint).

Fix: Prevent polling the model if we know that test is still scheduled. We do need setModel(undefined); to immediately clear the old steps in the UI, else when re-running a test, the old steps will remain visible until the test has started.

Side note: There are still quite a lot of console errors when running a test in UI mode.

Closes: #38359

[pavelfeldman]

With the present implementation, I don't see how this effect re-triggers and sets up the polling:
outputDir, item, setModel, counter, setCounter, pathSeparator - they all seem to be static.

From your comment, it seems like the issue is due to "Since there now is a model, useSources will instead try to fetch the source file from sha1/src, but with an empty trace URL.". We should handle it and still be able to return the fallback location.

[cpAdm]

item is in fact not static. It gets (indirectly) updated via sortAndPropagateStatus on testTree:

playwright/packages/trace-viewer/src/ui/uiModeView.tsx

Line 254 in 3a5a32d

testTree.sortAndPropagateStatus();

But maybe we should not rely on this implicit prop change?

For now I changed useSources to also refetch on 500 error code.

I am just not quite satisfied with all the console/SW errors that occur during any test. Notice the workIndex of -1 in /contexts fetches - which I tried avoid making by looking at item.treeItem?.status

[pavelfeldman]

I am just not quite satisfied with all the console/SW errors that occur during any test. Notice the workIndex of -1 in /contexts fetches - which I tried avoid making by looking at item.treeItem?.status

I agree, let's figure something out for this