[BUG] Scoped Namespace determination breaks earlier code with nested state

[andrew-chargesim]

#634 became a breaking change where updated objects were inserted as subsets of the original rather than replacing it.

e.g.

state={user:{status: 'logged_in'}}

then in an action:
state.user.status = 'logged_out'

mutates the state to:
state={user:{status:'logged_in', user:{status:'logged_out'}}}

It looks like this is since it is automatically assuming a scoped namespace, based on namespace length. This works for a single level state, but on an already multi-level state gets confused breaking earlier code.

[henri-hulski]

Thanks for the feedback. This needs to be fixed. Do you have a codebox to reproduce this issue?

[andrew-chargesim]

Digging into it, it only occurs when the action is also a subset - e.g. actions.user.logout instead of actions.logout without using the namespace configuration explicitly.

This is a breaking change between 28.1.0 and 28.2.0, the code below demonstrates it.

 * Example reproduction for Overmind bug #638
 *
 * This example demonstrates how, updating a nested property can incorrectly insert a copy
 * of the parent object under itself.
 */

import {createOvermind} from 'overmind'


// Define a module which contains a nested state.

const overMindConfig = {
    state: {
        user: {
            status: 'logged_in',
        },
    },
    actions: {
        user:
            {
                logout({state}: any) {

                    state.user = {status: 'logged_out'}
                },
            }
    },
}

// Create the Overmind instance and run the action.
const overmind = createOvermind(overMindConfig)

console.log('Initial state:')
console.log(JSON.stringify(overmind.state, null, 2))

// Call the action that triggers the bug.
overmind.actions.user.logout()

console.log('State after calling logout():')
console.log(JSON.stringify(overmind.state, null, 2))

/*
 * Expected console output (buggy behaviour):
 *
 * Initial state:
 * {
 *     "user": {
 *       "status": "logged_in"
 *     }
 * }
 *
 * Works as expected on 28.1.0:
 * {
 * "user": {
 *   "status": "logged_out"
 *      }
 * }

 * State after calling logout() on 28.2.0:
 * {
 *     "user": {
 *       "status": "logged_in",
 *       "user": {
 *         "status": "logged_out"
 *       }
 *     }
 * }

 */

[henri-hulski]

@andrew-chargesim this was quite tricky to fix. I had to go quite low-level and move the state transformation to proxy-state-tree.
I have published the fix as next release. Can you npm install overmind@next overmind-react@next and check if everything works? Then I can make a stable release.

[andrew-chargesim]

yes, I saw the changes are quite extensive.

I updated to our app to

"overmind": "^28.2.1-1764940847900",
"overmind-react": "^29.2.1-1764940847900",

via the next install as you suggested compared to 28.2.0 and our code appears to be working fine, so it looks like the fix solves the issue.

Thanks for your quick attention on this.

[henri-hulski]

The fix is published in Overmind 28.2.1.

https://github.com/cerebral/overmind/releases/tag/v2025-12-05_1709