MoveFolder throws “Cannot move root folder” when moving non-root user folders (.NET SDK)

[YoussefFenetre]

Summary

Calling IVault.MoveFolder(srcFolderUid, dstFolderUid, link:false) throws:

KeeperSecurity.Vault.VaultException: 'Cannot move root folder'

…even though both srcFolderUid and dstFolderUid refer to regular user folders (not the personal root and not a Shared Folder root).

SDK / Environment

Package: Keeper.Sdk (C#) — [1.0.7-beta01]

.NET: [8.0]

OS: [Windows/macOS/Linux + version]

Minimal repro

// Preconditions: authenticated VaultOnline `vault`
await vault.SyncDown();

// 1) Create a parent and two child folders (purely in "My Vault")
var parent = await vault.CreateFolder("TmpParent");                // under personal root
var src    = await vault.CreateFolder("SrcA", parent.FolderUid);   // TmpParent/SrcA
var dst    = await vault.CreateFolder("DstB", parent.FolderUid);   // TmpParent/DstB

// 2) Attempt to move SrcA under DstB
await vault.MoveFolder(src.FolderUid, dst.FolderUid, link: false);

Expected behavior

SrcA is moved under DstB with no error (since neither folder is a root).

Actual behavior

An exception is thrown:

KeeperSecurity.Vault.VaultException: 'Cannot move root folder'
at KeeperSecurity.Vault.VaultOnlineFunctions.MoveToFolder(...)
at KeeperSecurity.Vault.VaultOnline.MoveFolder(...)

What I verified

srcFolderUid != vault.RootFolder.FolderUid

vault.TryGetFolder(srcFolderUid, out var srcNode) returns a node whose:

ParentUid = parent.FolderUid (non-null)

Same checks for dstFolderUid pass.

Repro occurs even in a brand-new, empty structure created just before the call (see code above).

The Keeper web/desktop app can move the equivalent move successfully.

Notes / Additional context

I also encountered this related server response in other scenarios (possibly permission-related):

KeeperSecurity.Authentication.KeeperApiException:
missing: {"from_type":"user_folder","cascade":true,"can_edit":false,"can_reshare":false,"type":"user_folder","from_uid":""}

However, the minimal repro above is brand-new/empty folders and still throws the root error.

Request

Is this a regression or stricter classification of “root” for top-level user folders?

If intended, what is the recommended SDK sequence to “reparent” a non-root user folder within the personal tree?

If not intended, please advise a workaround or fix.

[sk-keeper]

Thank you for reporting this issue. It's been fixed in the 1.1.2 Beta02 release.
Please let us know if you need this fix in the 1.0.7 branch. We will propagate this fix to 1.0.7 branch

[YoussefFenetre]

Thank you for the fix. If you could propagate the fix in 1.0.7 it would be great.

[sk-keeper]

1.0.7 Beta02 release has this fix included