Problem
Two separate Pinia stores are registered under the same ID 'proxmoxSettings':
src/stores/proxmoxSettingsStore.ts → defineStore('proxmoxSettings', ...)src/composables/useProxmoxSettings.js → defineStore('proxmoxSettings', ...)
Pinia uses the store ID as a unique key. When two stores share the same ID, whichever is registered first wins and the second silently gets the first store's state and actions instead of its own. This leads to unpredictable behaviour at runtime — notably, components using one store may receive data from the wrong store.
The two stores also have different storage backends (localStorage vs cookies) and different APIs, making the collision a hard-to-debug correctness bug.
Expected
Each store must have a unique ID. The TypeScript store (proxmoxSettingsStore.ts) should be renamed to 'proxmoxSettingsLegacy' or removed if superseded by the JS composable store.
Impact
Runtime state corruption: settings saved through one store may silently be ignored or overwritten by the other.
Problem
Two separate Pinia stores are registered under the same ID
'proxmoxSettings':src/stores/proxmoxSettingsStore.ts→defineStore('proxmoxSettings', ...)src/composables/useProxmoxSettings.js→defineStore('proxmoxSettings', ...)Pinia uses the store ID as a unique key. When two stores share the same ID, whichever is registered first wins and the second silently gets the first store's state and actions instead of its own. This leads to unpredictable behaviour at runtime — notably, components using one store may receive data from the wrong store.
The two stores also have different storage backends (localStorage vs cookies) and different APIs, making the collision a hard-to-debug correctness bug.
Expected
Each store must have a unique ID. The TypeScript store (
proxmoxSettingsStore.ts) should be renamed to'proxmoxSettingsLegacy'or removed if superseded by the JS composable store.Impact
Runtime state corruption: settings saved through one store may silently be ignored or overwritten by the other.