Skip to content
This repository has been archived by the owner on Oct 23, 2022. It is now read-only.

Starting multiple inmemory instanced does not work #481

Closed
matthiasbeyer opened this issue Dec 4, 2021 · 6 comments
Closed

Starting multiple inmemory instanced does not work #481

matthiasbeyer opened this issue Dec 4, 2021 · 6 comments
Labels
bug Something isn't working

Comments

@matthiasbeyer
Copy link

Describe the bug

In my codebase:

---- client::tests::test_post_text_blob stdout ----                                                                   
thread 'client::tests::test_post_text_blob' panicked at 'called `Result::unwrap()` on an `Err` value: The repository is already being used by an IPFS instance.', src/client.rs:130:106                                                     
                                                                                                                      
---- client::tests::test_post_text_chain stdout ----       
thread 'client::tests::test_post_text_chain' panicked at 'called `Result::unwrap()` on an `Err` value: The repository is already being used by an IPFS instance.', src/client.rs:130:106

Expected behavior

Tests run in parallel

Additional context

Running multiple in-memory nodes should be possible, as rust tests run in parallel.

@matthiasbeyer matthiasbeyer added the bug Something isn't working label Dec 4, 2021
@koivunej
Copy link
Collaborator

koivunej commented Dec 5, 2021

I suspect this is the safety feature of having a lock file in the repository to guard against accessing it from two different processes. In fact, before this feature was added, there were a number of issues of me accidentially using the single repository and getting bad results, and wasting time.

You could for example use a temporary directory for this the purpose of testing.

@matthiasbeyer
Copy link
Author

How would a temporary directory help if everything is in memory anyways?

@koivunej
Copy link
Collaborator

koivunej commented Dec 5, 2021

No, it should not help, nor should it be needed. If this was the case, it'd be a bug. Could you share how are you hitting this issue with in-memory repository? Initialization code, and/or other details would help, or those in comparison to the tests in the repository.

@matthiasbeyer
Copy link
Author

Yeah, sure: https://git.beyermatthi.as/distrox/tree/src/client.rs?h=ipfs-backend#n127

It is just very simple stuff as I'm still playing with ideas... I am doing nothing more than just cargo test, which executes tests in parallel and then causes all tests to fail because the initialization of the ipfs repo fails for all tests.

@koivunej
Copy link
Collaborator

koivunej commented Dec 5, 2021

On line 130:

let (ipfs, fut): (ipfs::Ipfs<ipfs::Types>, _) = ...

Please try replacing ipfs::Types with ipfs::TestTypes. This is unfortunate fallout from some refactoring which removed the generic type being carried around with IpfsOptions without the naming becoming more clear.

@matthiasbeyer
Copy link
Author

Argh. Thanks!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants