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
[FIX] website_sale: prevent race condition on tour #44113
Conversation
@d-fence I wasn't able to reproduce it, but based on the logs I think it makes sense, could you check the commit message and gimme your feedback? |
cc @JKE-be As you already have worked on this one, maybe you have some other input on this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Do you need a runbot multi-build on your branch ?
5b160f5
to
e6eb468
Compare
e6eb468
to
bfb5a79
Compare
JKE enabled multi-build, I'll rebuild 10-20 times to ensure 150-300 builds are green (or not). |
@d-fence By no mean I am 100% sure this is fixing the issue. But in theory it should. |
I agree, I just put back the "Split" config and I will rplus |
I wait the last split to finish and rebuild with the Split config |
@rdeodoo can we test with a light page instead of /shop |
Ok, I re-enabled multi-build to check with a lighter page |
If it works with shop it will works with another page. |
ok, back to Split then |
@JKE-be Yes I know it would be better, I thought about it. I used homepage at first but no way to know we landed on homepage. I just need a page with an unique element on it. |
As this race condition seems not possible to be reproduced in local, all this is an assumption based on the logs. After the checkout, the user is redirected to `/shop/confirmation` where there is RPCs fired ever seconds to fetch the payment status (`/shop/payment/get_status`). As the test was considered as finished on that page, sometimes the RPC would still be processed in python while the tour was considered done and killed, thus also the cookies, session & co. From that point, the python would crash when accessing the session. In the logs, the python crash in the RPC call occurs after the test is done.
bfb5a79
to
7764246
Compare
Chang done, this can be r+? |
@robodoo r+ Thx |
As this race condition seems not possible to be reproduced in local, all this is an assumption based on the logs. After the checkout, the user is redirected to `/shop/confirmation` where there is RPCs fired ever seconds to fetch the payment status (`/shop/payment/get_status`). As the test was considered as finished on that page, sometimes the RPC would still be processed in python while the tour was considered done and killed, thus also the cookies, session & co. From that point, the python would crash when accessing the session. In the logs, the python crash in the RPC call occurs after the test is done. closes #44113 Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
If I am correct, this one did not appear since it was fixed 👍 |
@rdeodoo True. 👍 |
As this race condition seems not possible to be reproduced in local, all this
is an assumption based on the logs.
After the checkout, the user is redirected to
/shop/confirmation
where thereis RPCs fired ever seconds to fetch the payment status
(
/shop/payment/get_status
).As the test was considered as finished on that page, sometimes the RPC would
still be processed in python while the tour was considered done and killed,
thus also the cookies, session & co.
From that point, the python would crash when accessing the session.
In the logs, the python crash in the RPC call occurs after the test is done.