Is there any risk of multiple threads accessing this std::regex at the same time via std::regex_match? If so, is that behavior thread-safe?

Is there any risk of multiple threads accessing this std::regex at the same time via std::regex_match? If so, is that behavior thread-safe?

Constant regexp is thread-safe, we don't have mutations here.
It's safe to use it std::regex_match from multiple threads with const immutable std::regex.

Do we need to use word boundaries \b here? Do they improve anything?

What do you think about reducing the duplication in this regex? Do you think it is more readable, or should we keep the current approach?
[0-9a-f]{8}-([0-9a-f]{4}-){3}[0-9a-f]{12}

We can omit using \b here. I've removed them.

What are the exceptions that we expect here?

I think we can catch regex_error here.

Why cannot we throw in validateSessionID and let the current catch handle the rest?

Why cannot we throw in validateSessionID and let the current catch handle the rest?

Why cannot we just throw here?

Why cannot we throw in validateSessionID and let the current catch handle the rest?

If we throw an error here we can't log here and can return only one type of status code for grpc (which is described in catch).

I'm sure we must think about logging the errors at the server-side and returning the detailed description to the client, because in case of error even if don't have the server logs we can rely on the user's bug report with the error and description that he received.

In the app full-cycle, it works like: client app received an error and suggests the user fill the bug report or even send it automatically if the user agreed on this permission. That's why we need to send to the client detailed errors, to catch and resolve the possible bugs in the future.

Why cannot we just throw here?

It's not a good practice to throw an error inside the shared function and catch that error at the "upper" caller level. It will hard to debug this way and use this function properly.