-
Notifications
You must be signed in to change notification settings - Fork 149
Test TemplateProvider OS E13 #1278
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
Comments
re-opening as this is still happening, unfortunately #1293 didn't fix it also, this is not particular to the some recent failed executions (which went away by re-running): |
If this issue is raised again, I suggest to create a user in the CI and give it the correct permissions for writing/creating files. |
what I reported on #1374 is not unique to CI runs, I also witnessed it locally |
possibly related: rust-bitcoin/bitcoind#90 |
looks like we should be able to get similar functionality (and ongoing support) from https://crates.io/crates/corepc-node perhaps switching dependencies could improve things? or at least if we continue getting this problem, we could eventually report it and get support from the maintainers |
I was able to make some progress in investigating this problem. My strategy consisted of writing the following script: When running this script with enabled line 30 and disabled line 31 (running one isolated integration test instead of all tests concurrently), the script loop repeated for over 24h (tens of thousands of execution loops) without ever running into the permission error. When running the script with enabled line 31 and disabled line 30 (running all tests concurrently), after 26 loops the permission error was triggered. This indicates that the current execution strategy, where multiple tests in the same file are executed in parallel, is likely causing some kind of race-condition under the hood. |
might be related to exclusive access to resource during execution. |
tbh I don't think this is a wise way to fix this problem I already said a few times in the past that it's a very bad idea to be executing Integration Tests in parallel what we are witnessing here is just one of the many potential problems that can come from this just to name another that I see coming around the corner: having CPU miners running in parallel while fine-tuning difficulty targets based on measured hashrate will create a bunch of non-deterministic behaviors that will not be fun to debug I still don't understand the motivations for running Integration Tests in parallel... whatever optimizations we get in execution time are very marginal, and code organization is very subjective and can be achieved in different ways without parallel execution as a pre-requisite why can't we establish that ITF can only execute one test at a time? @jbesraa is this something you are highly opinionated about? if yes, can you elaborate on why? |
I'm not completely opposed. I'd prefer other options, but I'm open to trying it. |
ran the script again, now with
the line where |
TemplateProvider in integration-tests fails to start(sometimes) because it cant access OS folders
https://github.com/stratum-mining/stratum/actions/runs/12231267837/job/34113994881?pr=1242#step:4:377
The text was updated successfully, but these errors were encountered: