-
Notifications
You must be signed in to change notification settings - Fork 192
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 for issue #883 #889
Fix for issue #883 #889
Conversation
The behaviour after this fix seems normal. 48 PwWorkflows have been launched (not finished yet) that each of them has sub-workflows and I don't see the previous problems. |
@@ -181,3 +180,49 @@ def test_session_update_and_expiration_4(self): | |||
code.store() | |||
|
|||
self.drop_connection() | |||
|
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.
I would also add a test without any SQL specific command (in this case expunge_all
etc), as this is what the user would do (this could be a generic test) that would have triggered the error before.
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.
This is a good point.
The problem is that I have not managed to find until today (and it has been a while that I investigate this) a way to isolate the problem at that level (which more or less implies to follow the DbNode object generation in @nmounet workflows - that run by a Daemon that I don't control by my debugger).
Maybe an idea is if I can easily advance the steps of the daemon manually to emulate the daemon steps and see if I have the same behaviour. And if it is true to check what happens at every step with the session and the dbnodes. But this will not be a 10-20 mins job.
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.
Ok. For now, then, at least add the same identical test (but without any sqla command) as a general test. Then for me we can merge. Thanks!
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.
OK, I will.
Just keep in mind that it will be a test that doesn't test anything. I.e. that test would not fail even with the problematic code of set_value() that was corrected.
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.
I created the test but I did not push it yet. Let's have a short chat before I add it to this PR.
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.
ok, I see. Let's merge this, then.
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.
See my comment
(Fix for issue #883)
It seems to run with one WF. It would be good to launch many before merging it.
But in any case, it is an improvement comparing to the previous case