Duplicates in Identifier Cache

[CraigHarley]

Bug report

• I've checked documentation and searched for existing issues and discussions
• I've made sure my project is based on the latest MST version
• Fork this code sandbox or another minimal reproduction.

Unfortunately, not able to reproduce this (it happens in a closed source project - but it seems to happen when attempting to replace a stores data).

Describe the expected behavior

Should replace values in identifier cache without duplicates.

Describe the observed behavior

Error:

Forked MST so I could add logging:

If I drill into the two items, they're both basically identical - but they have different states 🤔

Any help would be appreciated.

The project is a NextJS app with the stores in a TurboRepo internal package (the problems started when I moved the stores to an internal package).

[CraigHarley]

Possibly related, I get weird intermittent errors: "assertion failed: the creation of the observable instance must be done on the initializing phase"

So I added some logging:

It does it fine for a bunch of objects:

But then fails when it hits a specific one:

[coolsoftwaretyler]

Hey there - thanks for the details so far. I still can't be super helpful without a reproduction. Any chance you can write some sample code outside of your project that reproduces the behavior? Or show a snippet of what you're trying to do at the time of the error?

The project is a NextJS app with the stores in a TurboRepo internal package (the problems started when I moved the stores to an internal package).

And some conjecture: any chance you're somehow duplicating stores/duplicating nodes as some side-effect of instantiating or importing from this package?

[CraigHarley]

Hi, thanks for the prompt reply

This is how I'm instantiating the store:

packages/shared_frontend/stores/store.ts

"use client";

export const Store = types.model({
  // lots of stores
})


const isServer = typeof window === 'undefined'
enableStaticRendering(isServer)

let RootStore = null
export const getRootStore = (): IRichStore & Store => {
    if (isServer) {
        return Store.create({});
    }

    if (!RootStore) {
        RootStore = Store.create({})
    }

    return RootStore
}

export const useStore = (): Store & IRichStore => useContext<Store>(StoreContext)
const StoreContext = createContext<Store>(getRootStore())
export const StoreProvider = StoreContext.Provider

Then in the App's layout.tsx, I have a component like:

export default function Providers({ children }) {
        return (
                <StoreProvider value={getRootStore()}>
                        {children}
                </StoreProvider>
        )
}

Then I access the store using useStore (in a component) or getRoot(self) (inside a store).

any chance you're somehow duplicating stores/duplicating nodes as some side-effect of instantiating or importing from this package?

That was my thought too, however I tried using window.RootStore, which (I would expect) should mean it just overwrites rather than running into weird let scope problems.

I still can't be super helpful without a reproduction

I'll have another go at this, I did try and it all seemed to work ok with simple stores just adding stuff on a useEffect (to simulate an update) - but the problem seems to happen a bit later on (after the initial render) once API requests are happening on the frontend.