Random access denied errors on User Extensions

Question

When using extensions in the Graph API:

graphUser = graphClient.Users.Request().AddAsync(graphUser).Result;

OpenTypeExtension newExtension = new OpenTypeExtension()
{
    ExtensionName = "CustomName",
    AdditionalData = new Dictionary<string, object>
    { { "CustomID", user.CustomID }
    }
};

graphClient.Users[graphUser.UserPrincipalName]
    .Extensions
    .Request()
    .AddAsync(newExtension)
    .Wait();

I randomly get these errors:

Code: AccessDenied
Message: Access Denied

Sometimes it works, sometimes it doesn't. I can't seem to find a correlation. When I step trough the code in the debugger it works more often then if I run it without interruption. But if I add a sleep between the lines (to account for processing delay), it doesn't fix the issue.

The application has all the required rights to access the API.

The issue isn't solely in the POST, but also on the GET as illustrated in the code sample below which results in the same error.

User user = graphClient.Users[userName]
    .Request()
    .GetAsync()
    .Result;

user.Extensions = graphClient.Users[userName]
    .Extensions
    .Request()
    .GetAsync()
    .Result;

Does anyone have experience with this issue? Thanks in advance!

EDIT:

I figured out that once the errors start showing, the user needs to be deleted. Errors on one user don't necessarily mean errors on another user.

EDIT 2:

I also posted this as an issue on GitHub. Here you can find more information about this problem. It's now labeled as a bug.

Answer 1

It turns out that the User Principal Name is a cached reference. Since I was running tests, meaning recreating the same test user a lot, the reference UPN was pointing to the old user object resulting in the Access Denied errors.

The issue can be avoided by using the Id of the object, like this:

 graphClient.Users[graphUser.Id]
    .Extensions
    .Request()
    .AddAsync(newExtension)
    .Wait();

I believe the team is going to fix the reference bug, but I can't speak for them of course. In either case I would recommend using the Id attribute to be sure.