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.

Sign up for GitHub

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

[Discover] Unskip functional discover request counts test and skip ES|QL part #205690

Merged
merged 1 commit into from
Jan 9, 2025
+31 −26
Merged

[Discover] Unskip functional discover request counts test and skip ES|QL part #205690

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
57 changes: 31 additions & 26 deletions test/functional/apps/discover/group3/_request_counts.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -28,8 +28,7 @@ export default function ({ getService, getPageObjects }: FtrProviderContext) {
const log = getService('log');
const retry = getService('retry');

// Failing: See https://github.com/elastic/kibana/issues/205344
describe.skip('discover request counts', function describeIndexTests() {
describe('discover request counts', function describeIndexTests() {
before(async function () {
await esArchiver.loadIfNeeded('test/functional/fixtures/es_archiver/logstash_functional');
await esArchiver.loadIfNeeded('test/functional/fixtures/es_archiver/long_window_logstash');
Expand All @@ -54,30 +53,34 @@ export default function ({ getService, getPageObjects }: FtrProviderContext) {
});

const expectSearchCount = async (type: 'ese' | 'esql', searchCount: number) => {
await retry.try(async () => {
if (searchCount === 0) {
await browser.execute(async () => {
performance.clearResourceTimings();
});
}
await waitForLoadingToFinish();
const endpoint = type === 'esql' ? `${type}_async` : type;
const requests = await browser.execute(() =>
performance
.getEntries()
.filter((entry: any) => ['fetch', 'xmlhttprequest'].includes(entry.initiatorType))
);
await retry.tryWithRetries(
Copy link
Member Author

Choose a reason for hiding this comment

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

I've rewrote this part, because it's simpler for debugging. when starting this test, going to get a coffee, tryWithRetries failes earlier than try. And it makes no sense here to wait too long

`expect ${type} request to match count ${searchCount}`,
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
`expect ${type} request to match count ${searchCount}`,
`expect ${type} request to match count ${searchCount}, but received ${count}`,

Nit: If these fail in the future, the logs won't include the received count. Not a big deal, but could be worth defining count above so we can log it here.

Copy link
Member Author

Choose a reason for hiding this comment

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

I think tryWithRetries works similar to try. it's using retryForSuccess under the hood:

kibana/packages/kbn-ftr-common-functional-services/services/retry/retry.ts

Line 113 in 9d22e8c

return await retryForSuccess<T>(this.log, {

and since the expect in the try function hasn't change, there should be no problem here?

I think it's waitFor that works differently?

kibana/packages/kbn-ftr-common-functional-services/services/retry/retry.ts

Line 83 in 9d22e8c

public async waitFor(

Copy link
Contributor

Choose a reason for hiding this comment

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

I was suggesting to include count so it would still be logged when the test fails, but I think I may have misunderstood what the passed string if for. I was thinking it would override the original error message, e.g. expected 4 to equal 3, but I see now the param is called description, so maybe it's used for something else and the original error is still logged on failure. I think we're all good here though and can merge this.

async () => {
if (searchCount === 0) {
await browser.execute(async () => {
performance.clearResourceTimings();
});
}
await waitForLoadingToFinish();
const endpoint = type === 'esql' ? `${type}_async` : type;
const requests = await browser.execute(() =>
performance
.getEntries()
.filter((entry: any) => ['fetch', 'xmlhttprequest'].includes(entry.initiatorType))
);

const result = requests.filter((entry) =>
entry.name.endsWith(`/internal/search/${endpoint}`)
);
const result = requests.filter((entry) =>
entry.name.endsWith(`/internal/search/${endpoint}`)
);

const count = result.length;
if (count !== searchCount) {
log.warning('Request count differs:', result);
}
expect(count).to.be(searchCount);
});
const count = result.length;
if (count !== searchCount) {
log.warning('Request count differs:', result);
}
expect(count).to.be(searchCount);
},
{ retryCount: 5, retryDelay: 500 }
);
};

const waitForLoadingToFinish = async () => {
Expand Down Expand Up @@ -257,8 +260,10 @@ export default function ({ getService, getPageObjects }: FtrProviderContext) {
});
});
});

describe('ES|QL mode', () => {
// Currently ES|QL checks are disabled due to various flakiness
// Note that ES|QL also checks for different number of requests due to the fields request triggered
// by the ES|QL Editor
describe.skip('ES|QL mode', () => {
const type = 'esql';
before(async () => {
await common.navigateToApp('discover');
Expand Down
Loading