Swinject: The depth cannot be negative fail

[diwengrum]

I'm getting this assertion error when trying to resolve dependency. It not happens every time, so I cannot figure out how to reproduce it and what it can be...

I'm using a global Container variable to access dependencies and then I have another global variable which contains all necessary dependencies registrations:

var DIContainer = Container()

var initDIContainer : () = {
    DIContainer.register(ReachabilityManagerType.self) { r in
        AFNetworkReachabilityManager.shared()
        }
        .initCompleted { r, manager in
            manager.startMonitoring()
        }
        .inObjectScope(.hierarchy)
       // and so on...
}

In my custom main.swift file I have _ = initDIContainer to early initialize dependencies.

But then, at random circumstances I get assertion failure here:

fileprivate let userProfileManager = DIContainer.resolve(UserProfileManagerType.self)!

Any ideas about what it can be?

[yoichitgy]

I'm not sure the cause of the problem, seeing the piece of code. Here are some hints.

1. Did you call resolve in a single thread?
2. Did you use v2.0.0-beta.2?
3. Any thread or dispatch queue is used in implementation or registration of UserProfileManagerType?

[yoichitgy]

Hello @diwengrum. Did you find any clue to reproduce the issue? Replying to the questions 1, 2 and 3 is helpful to investigate the issue.

[diwengrum]

@yoichitgy, I'm using Async Display Kit for my UI, so there are some UI elements being allocated on a background thread and they're calling resolve method. So basically I think the problem is that dependencies are sometimes resolved before they're registered on main thread.

[yoichitgy]

Did you use synchronize method for thread safety? If you use it, the problem might be resolved. Documentation is here:
https://github.com/Swinject/Swinject/blob/master/Documentation/ThreadSafety.md

[diwengrum]

@yoichgy, I'm using Async Display Kit for my UI, so there are some UI elements being allocated on a background thread and they're calling resolve method. So basically I think the problem is that dependencies are sometimes resolved before they're registered on main thread.