Avoid unnecessary user get expiring session memberships

[AlanCoding]

SUMMARY

This is something to speed up our middleware by 1 database query for every request.

ISSUE TYPE

• Performance

COMPONENT NAME

• API

AWX VERSION

4.0.0

ADDITIONAL INFORMATION

there seems to be no need to obtain the object at all, so we can just not do it. I tested the filter and create commands via the shell manually, and I know we have at least 1 functional unit test that covers this code path.

[softwarefactory-project-zuul]

Build failed.

• tox-awx-api-lint : SUCCESS in 1m 47s
• tox-awx-ui-lint : SUCCESS in 2m 43s
• tox-awx-api : RETRY_LIMIT in 41s
• tox-awx-ui : SUCCESS in 4m 14s
• tox-awx-swagger : SUCCESS in 6m 03s
• tox-awx-detect-schema-change : SUCCESS in 6m 28s (non-voting)

[AlanCoding]

recheck

[softwarefactory-project-zuul]

Build succeeded.

• tox-awx-api-lint : SUCCESS in 1m 51s
• tox-awx-ui-lint : SUCCESS in 2m 13s
• tox-awx-api : SUCCESS in 5m 44s
• tox-awx-ui : SUCCESS in 3m 56s
• tox-awx-swagger : SUCCESS in 6m 53s
• tox-awx-detect-schema-change : SUCCESS in 6m 38s (non-voting)

[rooftopcellist]

lgtm

[AlanCoding]

I have a gut feeling that I should rebase and test this with #3875 before merging it, so I will call it blocked until that lands. This makes the most sense in terms of simple merge order.

[softwarefactory-project-zuul]

Build succeeded.

• tox-awx-api-lint : SUCCESS in 2m 45s
• tox-awx-ui-lint : SUCCESS in 2m 55s
• tox-awx-api : SUCCESS in 5m 38s
• tox-awx-ui : SUCCESS in 3m 48s
• tox-awx-swagger : SUCCESS in 7m 04s
• tox-awx-detect-schema-change : FAILURE in 7m 48s (non-voting)

[AlanCoding]

recheck

[softwarefactory-project-zuul]

Build succeeded.

• tox-awx-api-lint : SUCCESS in 1m 50s
• tox-awx-ui-lint : SUCCESS in 2m 11s
• tox-awx-api : SUCCESS in 5m 32s
• tox-awx-ui : SUCCESS in 4m 16s
• tox-awx-swagger : SUCCESS in 7m 17s
• tox-awx-detect-schema-change : SUCCESS in 6m 49s (non-voting)

[AlanCoding]

Also want to test with rebase on top of #3918 and #3890

[AlanCoding]

This is kind of the gist of the answer I was looking for:

/venv/awx/lib64/python3.6/site-packages/django/contrib/sessions/middleware.py in process_response(58)
  request.session.save()
/venv/awx/lib64/python3.6/site-packages/django/contrib/sessions/backends/db.py in save(87)
  obj.save(force_insert=must_create, force_update=not must_create, using=using)
/venv/awx/lib64/python3.6/site-packages/django/dispatch/dispatcher.py in send(193)
  for receiver in self._live_receivers(sender)
/venv/awx/lib64/python3.6/site-packages/django/dispatch/dispatcher.py in <listcomp>(193)
  for receiver in self._live_receivers(sender)
./awx/main/signals.py in save_user_session_membership(658)
  if UserSessionMembership.objects.filter(user=user_id, session=session).exists():

I just wanted to have a sense of if and where this gets called from after the reordering. It seems that it is called from SessionMiddleware

https://github.com/django/django/blob/1.11.19/django/contrib/sessions/middleware.py#L58

Everything should be perfectly okay with that.

This is a post-save signal, and we are able to clearly identify the original save that happens

/venv/awx/lib64/python3.6/site-packages/django/contrib/sessions/middleware.py in process_response(58)
  request.session.save()
/venv/awx/lib64/python3.6/site-packages/django/contrib/sessions/backends/db.py in save(87)
  obj.save(force_insert=must_create, force_update=not must_create, using=using)

[softwarefactory-project-zuul]

Build succeeded (gate pipeline).

• tox-awx-api-lint : SUCCESS in 1m 49s
• tox-awx-ui-lint : SUCCESS in 2m 16s
• tox-awx-api : SUCCESS in 5m 40s
• tox-awx-ui : SUCCESS in 4m 15s
• tox-awx-swagger : SUCCESS in 6m 12s
• tox-awx-detect-schema-change : SUCCESS in 6m 21s (non-voting)
• awx-push-new-schema : SUCCESS in 5m 53s (non-voting)