Bug Report: `nsf-mkdir`/`nsf-rmdir`/`nsf-rndir` via Service Mode return wrong HTTP status and/or omit the folder UID

[kevtgenmab]

Component: keepercommander — Service Mode response parser
File: keepercommander/service/util/parse_keeper_response.py
Affected versions: 18.0.8, 18.1.1, 18.1.5

---

Summary

nsf-mkdir, nsf-rmdir, and nsf-rndir have no entry in _find_parser_method's exact_patterns dispatch table, so their Service Mode responses fall through to the generic heuristic parser _parse_logging_based_command. This causes two independent, observable defects:

This breaks the terraform provider for commander with NSF.

1. False HTTP 207. With the async queue enabled (service-create -q y), a sync-down triggered internally by the mkdir command runs inside the same async worker and can't find its own result, producing log text containing "not found". The heuristic parser sees both a success indicator and a not-found indicator in the combined log and injects {"status_code": 207} even though the folder was created successfully.
2. Empty top-level message. parse_response()'s is_from_log branch unconditionally calls _parse_logging_based_command(...), ignoring the parser_method_name already computed by _find_parser_method. Even when a dedicated parser is used, the folder UID is placed only in data.folder_uid — the standard top-level "message" field (which every other command populates and which callers typically read) is left empty. Additionally, the existing UID-matching regex only accepts base64url (no = padding), but NSF folder UIDs use standard base64 with = padding, so any regex-based fallback silently fails to extract them.

Reproduction

1. Start Service Mode with -q y (default).
2. POST /api/v1/executecommand {"command": "nsf-mkdir \"AnyFolder\""}.
3. Response is {"status": "partial_success", "status_code": 207, ...} instead of 200, and/or the top-level "message" field is empty even though data.folder_uid (if present) is correct.

Proposed Fix

• Add nsf-mkdir, nsf-rmdir, nsf-rndir to exact_patterns, routed to a dedicated parser that extracts the UID directly from the command's return value (immune to concurrent log noise) instead of the generic log-heuristic parser.
• Fix the is_from_log branch in parse_response() to honor the parser dispatch table rather than hardcoding _parse_logging_based_command.
• Have that parser accept standard base64 with = padding, and populate both data.folder_uid and the top-level "message" field with the UID — several downstream consumers key off message, not data.folder_uid.

References

• keepercommander/service/util/parse_keeper_response.py — _find_parser_method, parse_response, _parse_logging_based_command
• keepercommander/commands/nested_share_folder/folder_commands.py — NestedShareFolderMkdirCommand.execute()
• keepercommander/service/util/command_util.py — CommandExecutor.execute(), _status_code_from_response