Hi,

I would say if the server restarts so that the namespaces eventually are the same it is a design error, it should only allow connections after the namespaces are loaded.
In our SDK’s server side, you would need to only call UaServer.start after all NodeManagers are added. UaServer.init can be used to load the core namespace, so typically after that (or override the init method in the NodeManager). But if they are added after .start, then it is a race condition.

The spec says currently https://reference.opcfoundation.org/Core/Part5/v105/docs/6.3.1 “…
NamespaceArray defines an array of namespace URIs. This Variable is also referred as namespace table. The indexes into the namespace table are referred to as NamespaceIndexes. NamespaceIndexes are used in NodeIds in OPC UA Services, rather than the longer namespace URI. Index 0 is reserved for the OPC UA namespace, and index 1 is reserved for the local Server. Clients may read the entire namespace table or they may read individual entries in the namespace table. The Server shall not modify or delete entries of the namespace table while any client has an open session to the Server, because clients may cache the namespace table. A Server may add entries to the namespace table even if clients are connected to the Server. It is recommended that Servers not change the indexes of the namespace table but only add entries, because the client may cache NodeIds using the indexes. Nevertheless, it might not always be possible for Servers to avoid changing indexes in the namespace table. Clients that cache NamespaceIndexes of NodeIds should always check when starting a session to verify that the cached NamespaceIndexes have not changed.
…”

If you observe an index that is unknown, you could use UaClient.getNamespaceTable(true) to force re-reading it from the server. SDK currently does that automatically when it reconnects or if it has failed monitoreditems and recreating them is enabled (in it is at least in the latest version). The latter helps in this exact case if you create the MonitoredItems with uri-form ExpandedNodeIds, then their creation would fail (since no uri->index conversion possible) until there is an entry in the table. If it detects there other changes than just additions to the table it will log the warn because any previous index you have obtained previously can be invalid.