Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@wburns
Copy link
Contributor

@wburns wburns commented Jul 13, 2023

Closes #20983

Due to the replication happening a later point, the test could run in such a way that the session replication write to the cache was performed after the session had already "expired". In this test specifically the maxIdle would be -2 which SessionTimeouts signals as it is expired. This value of -2 was then passed to the ISPN cache which is inferred to be it cannot expire via maxIdle and thus it would not expire.

Note that this is only one of two issues I identified with the flaky test, but this one happens much more frequently. Please check #20983 or other issues regarding the other issue with the test that is not fixed here.

Copy link
Contributor

@martin-kanis martin-kanis left a comment

Choose a reason for hiding this comment

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

@wburns Thank you for the investigation and the fix. It looks good to me, however some other model tests failed. I'm not able to reproduce the failures locally.
I'm going to run more experiments in GHA to see if there is any problem.

@wburns
Copy link
Contributor Author

wburns commented Jul 14, 2023

@wburns Thank you for the investigation and the fix. It looks good to me, however some other model tests failed. I'm not able to reproduce the failures locally. I'm going to run more experiments in GHA to see if there is any problem.

I am not familiar with the other tests, but is it possible the test was inserting expired entries on accident and assuming it was not expired? It could be related to needing a pause to assert that an entry was inserted at the proper time like you did in #21701

@wburns
Copy link
Contributor Author

wburns commented Jul 17, 2023

Rebased to main

@martin-kanis
Copy link
Contributor

So I wasn't able to reproduce errors locally but it appeared again when I run model tests 10 times in GHA. In the logs, I see this error again but I don't see a connection between the error and changes in this PR.
However, I applied the same fix as in #16287 for the remote cache loader and run model tests 20 times: https://github.com/martin-kanis/keycloak/commits/21684-stability-check-2
Lets wait for the results. @vramik @wburns

@martin-kanis
Copy link
Contributor

With the "fix", there is still one timeout. It is happening also in main as reported in #21665, where I put my findings. Therefore, I'm approving this PR.

Copy link
Contributor

@martin-kanis martin-kanis left a comment

Choose a reason for hiding this comment

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

Actually, I just noticed the second commit. @wburns Can you please squash the commits?

@ahus1
Copy link
Contributor

ahus1 commented Jul 18, 2023

@wburns / @martin-kanis - I think the second commit is a merge commit, and I can squash this when merging PR. Ideally I'd like to see only one commit (as Martin mentioned), but I can fix this (hopefully) by pressing the right buttons here.

Copy link
Contributor

@ahus1 ahus1 left a comment

Choose a reason for hiding this comment

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

Approving as per @martin-kanis's approval.

@wburns
Copy link
Contributor Author

wburns commented Jul 19, 2023

Oh weird, sorry about the merge commit. I thought the rebase button did a rebase :(

This was referenced Sep 4, 2023
@stianst stianst mentioned this pull request Sep 11, 2023
@stianst stianst mentioned this pull request Nov 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Flaky test: org.keycloak.testsuite.model.session.SessionTimeoutsTest#testOnlineUserClientMaxLifespanSmallerThanSessionOverrideInClient

4 participants