Behavior-breaking change introduced in patch 2.5.3: Container.reset now resets defaultScope

[Mr-Alirezaa]

Hi,

In the 2.5.3 changelog, there’s a note stating:

• Container.reset should also reset defaultScope and promiseTriggersError.

While this may seem like a minor internal adjustment, it introduces a behavior-breaking change that can significantly impact existing codebases. Specifically, resetting a container now unexpectedly resets defaultScope, which was not the case before.

This change is problematic for two reasons:
1. Unexpected Side Effect: The name defaultScope does not imply that it would be reset as part of a Container.reset() call. Developers typically expect reset() to clear registered services or state, but not to modify the container’s configuration or intended usage patterns like scope behavior.
2. Violation of Semantic Versioning: This was introduced in a patch version. Patch releases are expected to be safe upgrades that fix bugs without introducing new behavior or breaking existing ones. In this case, the change silently altered runtime behavior and caused issues in production for us, which we only discovered through side effects.

Impact

This change broke expected behavior in our app. Here’s a simplified example:

public final class NetworkContainer: SharedContainer {
    public static let shared = NetworkContainer()
    public let manager = ContainerManager()

    public init() {
        manager.defaultScope = .cached
    }
}

Previously, dependencies resolved from NetworkContainer remained cached as intended. After upgrading to 2.5.3, calling reset() cleared the defaultScope back to .unique, which meant our dependencies were no longer cached — resulting in subtle bugs and inconsistent state.

Request

Please reconsider this change and how it was introduced. At the very least, such behavior changes should be reserved for a minor or major release, and should be more clearly documented as potentially breaking. In its current form, this violates the expectations developers have from patch versions.

[danielepantaleone]

When you reset a container using reset() you are implicitly passing .all as FactoryResetOptions.

If you are just interested in resetting registrations you should be using:

reset(options: .registrations)

[Mr-Alirezaa]

@danielepantaleone

Thats correct, but the change I mentioned still breaks the behavior for reset() and reset(options: .all) and I don't think this is acceptable in a patch version.

[danielepantaleone]

I see your point, but it's important to note that ContainerManager.defaultScope has always been declared as a variable, meaning it can be modified at any time from anywhere. The fact that you’re setting it once in the NetworkContainer constructor is just an implementation detail: it’s how you're choosing to use it. However, you shouldn’t assume the property will remain unchanged, since its definition as a variable inherently allows for mutation.

Conversely, if the intended behavior of defaultScope were to be immutable, i.e., "set once and never changed", it should have been defined as a read-only property within a protocol, with ContainerManager conforming to that protocol.

[Mr-Alirezaa]

Conversely, if the intended behavior of defaultScope were to be immutable, i.e., "set once and never changed", it should have been defined as a read-only property within a protocol, with ContainerManager conforming to that protocol.

This is reasonable and I accept it. However, at our work app, we’ve been using “Factory” since version 2.3.0 (This is what I remember). This behavior hasn’t changed until now. Considering the amount of time that’s passed, to me it seems like the intended behavior is that reset() doesn’t affect the defaultScope.

Thanks.

[hmlongco]

@Mr-Alirezaa "to me it seems like the intended behavior is that reset() doesn’t affect the defaultScope."

Another user pointed out that reset should in fact reset everything... and that includes the defaultScope and other properties of the container.

The documentation reads: "Resets the Container to its original state, removing all registrations and clearing all scope caches."

That fact that up to now it didn't reset defaultScope basically means that you were relying on undocumented behavior. The documentation never explicitly said defaultScope would be preserved on reset. But it does indicated that the reset() function exists to set the container back to an initial state.

The fact that defaultScope was omitted was an oversight in that regard and corrected.

The primary configuration mechanism for containers is autoRegister. Especially since that, for Container and Container.shared you don't have access to the initializer. If you'd set the default scope there the default would have been restored. But since you set the value in the object initializer, which only occurs once... it's not.

I get that you feel the existing behavior change should probably should have occurred in something other than a point release and I concur.

[Mr-Alirezaa]

@hmlongco Thanks for the clarification. I got your point and reasoning and we can go past that.

So, are you suggesting autoRegister is the right place for configuring the container? Am I right?