mismatch between user id in JSON response of created user and user id when looking it up in the database

[pdurbin]

I haven't committed this test yet, but I'm seeing a mismatch between the user id in JSON response of created user and user id when looking it up in the database:

Running edu.harvard.iq.dataverse.api.BuiltinUsersIT
{
    "status": "OK",
    "data": {
        "user": {
            "id": 11357,
            "firstName": "firstName",
            "lastName": "lastName",
            "userName": "37f9be2b",
            "email": "37f9be2b@mailinator.com"
        },
        "apiToken": "b92c8fc5-f513-4853-afcd-8e6570cf91ed"
    }
}
11357 was the id from JSON response on create
{
    "status": "OK",
    "data": {
        "identifier": "@37f9be2b",
        "id": 11356
    }
}
11356 was the id from the database

The bug seems to be in the JSON response because the new method I wrote to look up the id in the database returns the right id:

dataverse_db=# select id,useridentifier from authenticateduser where useridentifier = '37f9be2b';
  id   | useridentifier 
-------+----------------
 11356 | 37f9be2b
(1 row)

So the question is why the JSON coming back from creating the user via API is off.

I'm on commit e2d4fa3 as of this writing.

[pdurbin]

@scolapasta I'm going to give this to you to think about why we only see this bug with production data since I'm really not sure. I added a test in e45dd79 which you can execute by running mvn test -Dtest=BuiltinUsersIT or by clicking Cmd-F6 on the BuiltinUsersIT file in Netbeans.

The mismatch is making it difficult for me to write integrations tests with production data for #2036 so I'm going to match the milestone for that ticket.

[pdurbin]

Actually the new method added to api/Admin.java in e45dd79 is allowing me to move forward in my integration test writing. Basically, I don't trust the id value given back in the JSON when I create a user. I always double check with my new API endpoint what the actual database id is.

Oh, I wonder if @michbarsinai has any thoughts on this.

[michbarsinai]

We need to look at this in on the server - we're using plain JPA code there.

[pdurbin]

@michbarsinai maybe when you're in town we'll get a production database on your laptop so we can exercise the bug there.

[pdurbin]

I'm going to attach a tiny non-production database below that exercises this bug as of 4.2.3. I was adding and deleting a bunch of users and now this bug has appeared again. It's very mysterious to me. Anyway, once I upload the database I'm going to drop it locally because this bug is blocking my development of #2915.

Here's what I'm seeing right now:

171 was the id from the database
172 was the id from JSON response on create

Here's a sample database to reproduce this bug:

dataverse_db.sql.txt

[pdurbin]

@kcondon suggested that perhaps the JSON response when creating a bulitinuser shows the id from the builtinuser table rather than the authenticateduser table and he's absolutely right. In pull request #3124 I'm suggesting that we show both.

[kcondon]

OK, looks good, closing.

{"status":"OK","data":{"user":{"id":6,"firstName":"Pete","lastName":"Privileged","userName":"pete","affiliation":"Top","position":"The Boss","email":"pete@malinator.com"},"authenticatedUser":{"id":6,"identifier":"@pete","displayName":"Pete Privileged","firstName":"Pete","lastName":"Privileged","email":"pete@malinator.com","superuser":false,"affiliation":"Top","position":"The Boss","persistentUserId":"pete","authenticationProviderId":"builtin"},"apiToken":"a5a69e97-86c8-4934-bed8-01d6b0b625f3"}}