container.snapshot/restore behaviour changed in v7

[pfe-nazaries]

Is there an existing issue for this?

• I have searched the existing issues

Current behavior

After upgrading from 6.2.1 to 7.5.1 all vitest test that test classes with injectables are broken

I use this pattern to save the original container, rebind with mocks and restore original for each test

beforeEach(() => {
       container.snapshot();

       categoryDatasource = mock<CategoryRemoteDatasource>();

       container
           .rebindSync(CategoryRemoteDatasource)
           .toConstantValue(categoryDatasource);

       categoryRepository = container.get<CategoryRepository>(
           spaTypes.repositories.CategoryRepository,
       );
   });

   afterEach(() => {
       container.restore();
   });

Since the update is like snapshot or restore doesn't work, the container "remains" and "leaks" between test, they are not isolated anymore.

Steps to reproduce

No response

Expected behavior

Each test should get a "fresh" container base of the steps inside beforeEach

Possible solution

No response

Package version

7.5.1

Node.js version

22.15.0

In which operating systems have you tested?

• macOS
• Windows
• Linux

Stack trace

No response

Other

No response

[pfe-nazaries]

Also to mention, every test that fails, if I run that failed test alone, passes. But once I run one (that passes), the next one on the suite fails. So on every suite, just passes that first test that runs and the rest fails.

This points me in the direction that snapshot and restore don't work or at least don't work as before

[pfe-nazaries]

More details:

I just figure it out that the snapshot/restore behaviour is different and is related to singletons

If I remove singleton definitions, my test passes

So my guess is that snapshot/restore now keeps singletons created, and that should be not the behaviour, or at least would be a breaking change

[notaphplover]

Hey @pfe-nazaries, please provide a minimum reproduction code of the issue. It can be a reproduction repository or a code sandbox. We cannot investigate the issue without it.

So my guess is that snapshot/restore now keeps singletons created.

What do you mean? The singleton instance is kept in the binding and set in the snapshot, same way than v6. Let's try to recreate it in order to fix it 🙂

[pfe-nazaries]

Hey @pfe-nazaries, please provide a minimum reproduction code of the issue. It can be a reproduction repository or a code sandbox. We cannot investigate the issue without it.

So my guess is that snapshot/restore now keeps singletons created.

What do you mean? The singleton instance is kept in the binding and set in the snapshot, same way than v6. Let's try to recreate it in order to fix it 🙂

https://github.com/pfe-nazaries/inversify-repro

My guess is that:

In v6 i make the snapshot before running anything on the container, then run the test and the singleton is created. Because i made the snapshot before, when i run on beforeEach the restore, the container revert to it initial (empty) state without any instance of the singleton

In v7 seems to persist the instance even the snapshot was created before running anything from the container.

[weyert]

Yes, looks you can't call toConstantValue anymore on rebind(). E.g. container.rebind<Type>(SYMBOL).toConstantValue(value) doesn't work.

[notaphplover]

Hey @pfe-nazaries , I had a look at your reproduction code. The behavior is the expected one. To sumarize:

class Foo {};

const container: Container = new Container();

// The binding is added to the container.
container.bind(Foo).toSelf().inSingletonScope();

// The binding is resolved and the cached value is set to the binding.
const foo = container.get(Foo);

/*
 * A snapshot is created. Bindings are stored in the snapshot.
 * The cached value is not deleted, creating a snapshot does not delete a binding cached value.
 */
container.snapshot();

container.bind(class Bar {}).toSelf():

/*
 * The snapshot is restored. The cached value is not deleted, restoring a snapshot does not
 * delete a binding cached value. Bar binding is removed since it is not in the snapshot.
 */
container.restore();

// The binding is resolved and the cached value is reused
const foo2 = container.get(Foo);

expect(foo).toBe(foo2); // Expected to pass

As said, the cached value is not deleted. This is true in V7 and should be true in V6, if not, then it is not the expected behavior in V6.

If you want to have different instances when resolving the same service, maybe the singleton is not what you're looking for. I understand you want this behavior for testing purposes. Instead of using snapshots, I think you can create a child container and override the desired binding to be in transient scope. That would probably do the trick.

Is there anything else you'd like to discuss? If not, I will close the issue 🙂

[notaphplover]

Yes, looks you can't call toConstantValue anymore on rebind(). E.g. container.rebind<Type>(SYMBOL).toConstantValue(value) doesn't work.

Hey @weyert, is the issue you're describing related to this issue? If not, please submit an issue with a reproduction code.

[pfe-nazaries]

I can confirm that the behaviour changed between v6 and v7 (just downgrade to any v6 version on my repro)

[notaphplover]

Hey @pfe-nazaries, you're right, it's the behaviour in inversify@6. It's not the expected behavior since singleton scope bndings are initialized once and, as said in my previous comment, restoring a snapshot simply does that: restoring the container to its previous state. If the previous state has a singleton with a cached resolved value, so should be the case after restoring the snapshot. I consider v6 behavior as a bug solved in inversify@7. I'll update the changelog accordingly 🙂. I'm closing the issue, but feel free to continue the discussion if there's anything else you'd like to discuss.

[pfe-nazaries]

Hey @pfe-nazaries, you're right, it's the behaviour in inversify@6. It's not the expected behavior since singleton scope bndings are initialized once and, as said in my previous comment, restoring a snapshot simply does that: restoring the container to its previous state. If the previous state has a singleton with a cached resolved value, so should be the case after restoring the snapshot. I consider v6 behavior as a bug solved in inversify@7. I'll update the changelog accordingly 🙂. I'm closing the issue, but feel free to continue the discussion if there's anything else you'd like to discuss.

Hey @notaphplover

Just to be sure if i didn't explain it right or maybe it is me who is missing some key point here, quoting you:

restoring the container to its previous state. If the previous state has a singleton with a cached resolved value, so should be the case after restoring the snapshot.

On my repro the singleton is created for the very first time after the snapshot is done, so the previous state (when restoring) should be no singleton at all, as it was not created yet and therebefore no cached value should be resolved. This is the behaviour in v6, and the one that makes sense as you describe.

Point me if im missing something obvious, but following this reasoning the v7 is the one with the bug?

Hope this helps

[notaphplover]

Hey @pfe-nazaries, you're right, thanks for the explanation. On my way to solve it 🙂

[notaphplover]

inversify@7.5.2 has been released with a fix for this issue 🙂