There is definitely an issue here, and we're working on the right way to deal with it. I'll explain what's happening.

The Short Answer

There is another repository on your machine that has the user record in question. A push/pull from that repository into the one displaying only user ids will correct the problem.

The Long Answer

Each instance of a Veracity's repository has its own user list. That user list is pushed/pulled alongside version control changesets and all the other Veracity repository data.

The user list is also designed to be shared between different repositories, when correctly set up. When a repository is created, it gets an adminid. This is the unique identifier for its list of users. Two repositories having the same adminid can share their user lists via push/pull:

Create an empty repo with 2 users

PS C:\temp> vv repo new repo1
PS C:\temp> vv user create user1 --repo repo1
PS C:\temp> vv user create user2 --repo repo1
PS C:\temp> vv users --repo repo1
user1
    g879b297a70e947f895acc5c1a0142c44811302c35d6f11e1b97bf0def1557ebd
user2
    g4f5e1998397c4f31b8c15b3c6d437ba4857fbb275d6f11e1b97bf0def1557ebd

Create a different repo that can share the user list using --shared-users

PS C:\temp> vv repo new repo2 --shared-users repo1
Pulling user database... Done.
PS C:\temp> vv users --repo repo2
user1
    g879b297a70e947f895acc5c1a0142c44811302c35d6f11e1b97bf0def1557ebd
user2
    g4f5e1998397c4f31b8c15b3c6d437ba4857fbb275d6f11e1b97bf0def1557ebd

Create a new user in repo2 and push it to repo1

PS C:\temp> vv user create user3 --repo repo2
PS C:\temp> vv push --src repo2 repo1
Pushing user database... Done.

WARNING: The repositories are not clones of one another,
         but they belong to the same administrative group.
         Only the user database was pushed.

PS C:\temp> vv users --repo repo1
user1
    g879b297a70e947f895acc5c1a0142c44811302c35d6f11e1b97bf0def1557ebd
user2
    g4f5e1998397c4f31b8c15b3c6d437ba4857fbb275d6f11e1b97bf0def1557ebd
user3
    g043886d525234b0b9a4228e64a80ec7ece7e2a7c5d6f11e1b97bf0def1557ebd

That's mostly just background for this point: the scope for a Veracity user is its adminid. You can have n repositories on your machine with a given adminid. You can retrieve the adminid of a repository with 'vv repo info' and the '--verbose' flag:

PS C:\temp> vv repo info repo1 --verbose
Repository:           repo1

Descriptor:
{
        "path_parent_dir" : "C:/Users/iolsen/AppData/Local/.sgcloset/repo",
        "repo_id" : "g70b3801d4b53474f88a55573fbb1a0c57a8d012b5d6f11e1b97bf0def1557ebd",
        "admin_id" : "g761d72c6c10c47cea4db1764ff71a7ca7a8d012a5d6f11e1b97bf0def1557ebd",
        "storage" : "fs3",
        "dir_name" : "repo1_1196"
}

Because the scope of a user is the adminid, it's stored that way in the configuration:

PS C:\temp> vv whoami user1 --repo repo1
PS C:\temp> vv config

...
/admin/g761d72c6c10c47cea4db1764ff71a7ca7a8d012a5d6f11e1b97bf0def1557ebd/
    whoami/userid: g879b297a70e947f895acc5c1a0142c44811302c35d6f11e1b97bf0def1557ebd
...

Note that g761d... is the adminid of the 2 repositories we created above, and g879b... is the id for 'user1'.

The problem is that we check for user validity on 'whoami', but not on commit. So you can set 'whoami' using a repo that has a user, then commit into a repo with the same adminid but missing the relevant user record. This was deliberate, and if you squint just right you can imagine a case for that being the correct behavior, but at this point everyone agrees it's not: it's too confusing. We're working on a fix.