Created user with rest API does not exist immediately after creation

[ulrik_sandgren]

Hi

This is what I found when I checked our logs in our integration:

PostAsync uri:/api/v1/accounts/self/users, body:{ "user": { "name": "xx yy", "short_name": "xx yy", "sortable_name": "yy, xx", "terms_of_use": true }, "pseudonym": { "unique_id": "xxxyyy@umu.se", "sis_user_id": "zz" }, "communication_channel": { "type": "email", "address": "xx.yy@umu.se" }} 2020-04-24 10:08:18Z 17772 17
Leave CanvasService:AddNewUser() result: Id: xxxyyy@umu.se, UserId: 914 2020-04-24 10:08:19Z 17772 17
Enter CanvasService:EnrolUser() EnrolmentDto: TargetSystem: CANVAS, Site: {Person: {Id: xxxyyy 2020-04-24 10:08:19Z 17772 17
GetAsync uri:/api/v1/accounts/self/users?search_term=xxxyyy@umu.se 2020-04-24 10:08:19Z 17772 17
GetAsync uri:/api/v1/accounts/self/users?search_term=xxxyyy@umu.se 2020-04-24 10:08:20Z 17772 17
GetAsync uri:/api/v1/accounts/self/users?search_term=xxxyyy@umu.se 2020-04-24 10:08:23Z 17772 17

As you can see the user was created and a user id was returned, then a short time after the user is going to be enroled but Canvas can not find the user and the program makes 2 retries with a delay and finally finds the user.

Can anyone explain what is happening here, why does not Canvas find the user in the first attempt?

[James]

 @ulrik_sandgren  

This sounds very much like this thread: https://community.canvaslms.com/ideas/15924-course-creation-api-should-only-return-a-new-course-id-i... 

In that thread, it was the courses that were not being created, even though a course ID was getting returned and everything was successful.

That doesn't necessarily explain why Canvas cannot find something after saying it was created, just conjecture on my part about there being a heavy load. I don't agree that the request was the right one, because eventually it seems that the course was being created, it just wasn't available immediately.

I send all my stuff through a SIS import where I expect that it will run in the background and may take some time. Maybe the expectation that it exist immediately is unrealistic and there is additional background processing that needs done? Still, it seems that Canvas may have made some changes that are affecting this as I had not seen anyone complain about this until just recently.

I don't know if your code was an effort to track down the problem or it was what was actually happening when you first noticed the problem. Normally, I wouldn't think people would verify that user existed when the previous API call said that it did -- not until I saw the other thread that is.

I see you're using the search API and basing it off the login ID. That gives me ideas of two things to consider (I don't know that either is the reason, just things to explore more).

• Maybe the user has been created in the user table when the API call returns but then additional processing happens for adding the login information.
• You are using the search capability and I think those are cached. If you had done a search for the user to see if it was there, then added it when it wasn't, and then searched to see if it was there, it might be returning the cached version where the user wasn't there.

What happens if you try to access to user directly rather than by using the search feature? When you create the user, you get an ID back that you can use directly rather than by searching by their login ID. If 914 is the userID, then you could should use GET /api/v1/users/914 instead of GET /api/v1/accounts/self/users/?search_term=xxxyyy@umu.se

It took my system 1205.69 ms to search for my email address and about half that much time to use my user ID or my sis_user_id. The more I searched, the quicker it got (going back to the caching issue), eventually settling in on about 300 ms [and the search_term never got much faster than 850 ms]. If you don't save the user ID returned from the create user command, you could use GET /api/v1/users/sis_user_id:zz

[ulrik_sandgren]

I suspected that Canvas has some kind of cache that needs to be updated, thats the only answer that makes sense on this. I will investigate if we could make some changes to use use the user id instead of search the user, I guess that will solve this issue.

But I would like to see an answer from Instructure on this because I have not found anything on this in the documentation.

[maguire]

I have a program called "create-fake-users-in-course.py" at GitHub - gqmaguirejr/Canvas-tools: Some tools for use with the Canvas LMS.  that creates a set of fake users and enrolls them in a course. I have run it a lot in my own Canvas instance and never seen it fail. It enrolls the students in the course using their sis_user_id.  It is run as a user with all privileges.

See also the posting by @Canvas LMS Community  in https://instructure.jiveon.com/thread/1392?start=30&tstart=0 about unreliable matching on e-mail address.

You are correct that there is a very large amount of caching going on behind the scenes and there are a lot of different containers that are communicating. Also, since one is creating a new user - it can take sometime before the actual write to the database (and its distributed copies) completes. So it would not be at all surprising that one can have a race condition where the write has only happened in one instance and the other instances and the cache do not yet have this update.

Is your integration program (probably a node.js application) making the GetAsync call to list the account users?  If so, have you tried changing the timeout and retry count? Or tried doing an explicit await to that the creation of the user has completed?