761865 - [traceback] answer.question.answers is an empty list somehow

Status: RESOLVED FIXED

(support.mozilla.org :: Questions, task)

Description

[Will Kahn-Greene [:willkg] ET needinfo? me]

This specific answer kicks up an error whenever this task runs. Somehow it's in a funky state since answer.questions.answers is somehow an empty list.


Task questions.tasks.log_answer with id ecee65f6-cf82-4711-9357-442853651add raised exception:
"IndexError('list index out of range',)"


Task was called with args: (<Answer: Firefox 13 marked some themes incompatible: I believe Firefox objects when the maxversion is h>,) kwargs: {}.

The contents of the full traceback was:

Traceback (most recent call last):
  File "/data/www/support.mozilla.com/kitsune/vendor/src/celery/celery/execute/trace.py", line 181, in trace_task
    R = retval = fun(*args, **kwargs)
  File "/data/www/support.mozilla.com/kitsune/apps/questions/tasks.py", line 130, in log_answer
    if answer == answer.question.answers.order_by('created')[0]:
  File "/data/www/support.mozilla.com/kitsune/vendor/src/django/django/db/models/query.py", line 190, in __getitem__
    return list(qs)[0]
IndexError: list index out of range

Comment 1

[Will Kahn-Greene [:willkg] ET needinfo? me]

Two thoughts from the stand-up meeting where we talked about this:

1. It's possibly the case that there's a race condition with the cache and that answer.questions.answers sometimes comes out as an empty list. The solution here would be to not pull from cache.

2. We might be able to assume that if we ever hit an IndexError in this situation, that it's almost always the first answer. Therefore we can wrap this in a try/except and if we hit an IndexError, run FirstAnswerAction.

Comment 2

[Ricky Rosario [:rrosario, :r1cky]]

Bringing in to the current sprint because the traceback email is bothering me.

Comment 3

[Ricky Rosario [:rrosario, :r1cky]]

Landed in prod https://github.com/mozilla/kitsune/commit/99d06cd16fdfe4b664ecf4ede26351e49766b338