yahoo-eng-team team mailing list archive

[Boris Bobrov <2044624@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

Steps to reproduce:

1. You need a system with 2 scripts and a keystone user in sql, running in parallel:
Script 1 performs many authentications with username+password
Script 2 deletes the user

2. With enough luck, you get the following backtrace:

2023-11-25 19:56:10.675007 AttributeError: 'NoneType' object has no attribute 'last_active_at'
2023-11-25 19:56:10.674995 user_ref.last_active_at = datetime.datetime.utcnow().date()
2023-11-25 19:56:10.674993 File "/var/lib/openstack/lib/python3.10/site-packages/keystone/identity/shadow_backends/sql.py", line 161, in set_last_active_at

I think the reason is that in some cases authentication is slower than
deletion. Which results in a race condition: deletion process has
finished, but authentication is still mid-execution.

Expected: keystone either finishes the authentication successfully returning the token or raises a 4xx error
Observed: keystone crashes, resulting in error 500

** Affects: keystone
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/2044624

Title:
  set_last_active_at on deleted user results in AttributeError

Status in OpenStack Identity (keystone):
  New

Bug description:
  Steps to reproduce:

  1. You need a system with 2 scripts and a keystone user in sql, running in parallel:
  Script 1 performs many authentications with username+password
  Script 2 deletes the user

  2. With enough luck, you get the following backtrace:

  2023-11-25 19:56:10.675007 AttributeError: 'NoneType' object has no attribute 'last_active_at'
  2023-11-25 19:56:10.674995 user_ref.last_active_at = datetime.datetime.utcnow().date()
  2023-11-25 19:56:10.674993 File "/var/lib/openstack/lib/python3.10/site-packages/keystone/identity/shadow_backends/sql.py", line 161, in set_last_active_at

  I think the reason is that in some cases authentication is slower than
  deletion. Which results in a race condition: deletion process has
  finished, but authentication is still mid-execution.

  Expected: keystone either finishes the authentication successfully returning the token or raises a 4xx error
  Observed: keystone crashes, resulting in error 500

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/2044624/+subscriptions