Bump the limit of traces we see in e2e tests

[nrfox]

Describe the change

Attempts to fix tracing flakes like this one: https://github.com/kiali/kiali/actions/runs/13909420482/job/38920315175#step:8:766

Steps to test the PR

N/A

Automation testing

Included

[josunect]

Thanks for the fix, @nrfox ! It looks good.

Should we also fix this issue? https://github.com/kiali/kiali/actions/runs/13912310385/job/38929093053?pr=8247 It is not related but it is also related to tracing tests.

I think this https://github.com/kiali/kiali/blob/master/frontend/cypress/integration/featureFiles/app_details.feature#L48 should be details, probably, as we see in the image, maybe not all the spans are loaded yet, so productpage app is not found:

This is not happening with Jaeger, because, for what I understand, it is related to how the Tempo backend works, as results are indexed and might not be available at the time of the search.

[nrfox]

@josunect thanks for taking a look.

This is not happening with Jaeger, because, for what I understand, it is related to how the Tempo backend works, as results are indexed and might not be available at the time of the search.

I assumed that what was happening here was that we are only seeing a portion of the overall traces because of the limit so we might be missing traces from certain apps altogether? Would adjusting the duration down to 1m help?

[jshaughn]

@leandroberetta Is working on a new test app that provides predictable logs for our cypress tests. Would it be useful to ry and also have it generate predictable traces?

[nrfox]

@leandroberetta Is working on a new test app that provides predictable logs for our cypress tests. Would it be useful to ry and also have it generate predictable traces?

I think what makes the traces unpredictable is the tracing backend and not the app.

[josunect]

@leandroberetta Is working on a new test app that provides predictable logs for our cypress tests. Would it be useful to ry and also have it generate predictable traces?

I think what makes the traces unpredictable is the tracing backend and not the app.

Yes, I think that's the issue. Unless we select a custom time period (For example, getting from the last 10 to the last 5 minutes), I think it would be more likely to have all the results indexed.

[jshaughn]

I think what makes the traces unpredictable is the tracing backend and not the app.

Yes, I think that's the issue. Unless we select a custom time period (For example, getting from the last 10 to the last 5 minutes), I think it would be more likely to have all the results indexed.

I get that the indexing time is probably the issue. I didn't know whether it would be useful to generate something simple and consistent that could be sampled at 100%, or something. But, it doesn't sound like it would be helpful.

[nrfox]

@josunect I'm going to update this PR to instead pick a trace that is not in progress, one that has all of it's spans. I think that's the more direct cause for the flakes. I'll open a separate issue for the behavior of selecting an incomplete trace.

[nrfox]

@josunect hopefully this run passes if you want to take another look

[josunect]

Thank you, @nrfox ! It looks good