-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Closed
Copy link
Labels
s4Internal bugs (e.g. test flakes), extreme edge cases, and bug risksInternal bugs (e.g. test flakes), extreme edge cases, and bug risksscaletestIssues related to scale testing.Issues related to scale testing.
Description
Is there an existing issue for this?
- I have searched the existing issues
Current Behavior
While scale testing, a newly created user fails to log in.
Relevant Log Output
Error: create user: login as new user: POST https://primary.charlie.scaletest.dev/api/v2/users/login: unexpected status code 401: Your account is dormant. Contact an admin to reactivate your account.: Try logging in using 'coder login'.Expected Behavior
Newly created users can't be marked dormant by the job until 90 days after account creation.
Steps to Reproduce
Pretty sure this is a narrow race while the user is logging in, because we normally don't block login for dormant users.
user, err = ActivateDormantUser(api.Logger, &api.Auditor, api.Database)(ctx, user)
if err != nil {
httpapi.Write(ctx, rw, http.StatusInternalServerError, codersdk.Response{
Message: "Internal error.",
Detail: err.Error(),
})
return user, rbac.Subject{}, false
}
subject, userStatus, err := httpmw.UserRBACSubject(ctx, api.Database, user.ID, rbac.ScopeAll)
if err != nil {
logger.Error(ctx, "unable to fetch authorization user roles", slog.Error(err))
httpapi.Write(ctx, rw, http.StatusInternalServerError, codersdk.Response{
Message: "Internal error.",
})
return user, rbac.Subject{}, false
}
// If the user logged into a suspended account, reject the login request.
if userStatus != database.UserStatusActive {
httpapi.Write(ctx, rw, http.StatusUnauthorized, codersdk.Response{
Message: fmt.Sprintf("Your account is %s. Contact an admin to reactivate your account.", userStatus),
})
return user, rbac.Subject{}, false
}
First we activate the user, then re-query their status, and finally check whether it is now active. But, the dormant job could come in and mark the user dormant between these queries. It only checks last_seen_at, which isn't updated when the user is marked active.
For correct behavior, we should set last_seen_at in the query that activates the dormant user. This way the dormant job cannot mark us dormant again for 90 days.
Environment
- Host OS:
- Coder version:
Additional Context
No response
Metadata
Metadata
Assignees
Labels
s4Internal bugs (e.g. test flakes), extreme edge cases, and bug risksInternal bugs (e.g. test flakes), extreme edge cases, and bug risksscaletestIssues related to scale testing.Issues related to scale testing.