My workmate noticed that this bug is connected with result backend used by django-celery (DatabaseBackend).

Can't reproduce here. This is what I tried:

@task
def sleep_and_add(secs, x, y):
    from time import sleep
    sleep(secs)
    return x + y

>>> r = sleep_and_add.delay(10, 2, 2)
>>> r.ready()
False
>>> r.ready()
False
# 10 seconds passes
>>> r.ready()
True

>>> r = sleep_and_add.delay(10, 2, 2); r.ready(); r.ready()
False
False
# 10 seconds passes
>>> r.ready()
True

I've found the reason.

In short: it's issue caused by transaction isolation level - default REPEATABLE READ for MySQL/InnoDB.

Hitting more details:
step 1) r.ready() is performed before task is completed, using connection X to MySQL.
MySQLdb is by default in autocommit=OFF mode, so this SELECT was done inside transaction. Any further same-SELECT will return same result, no matter if row will be modified inside other connection. It's because how transaction works in isolation level REPEATABLE READ.

step 2) Task id completed, celeryd updates task status from connection Y, and commits.

step 3) r.ready() is performed , using connection X to MySQL. Despite row was modified, SELECT retuns same, obsolete result. So we would expect r.ready() to be True, but we get False.

Take look on SQL:

SELECT for result is done from conection 466
UPDATE is done from conection 467

100819 14:32:07   466 Connect   root@localhost on test
          466 Query SET storage_engine=INNODB, time_zone=UTC
          466 Query SET NAMES utf8
          466 Query set autocommit=0
          466 Query INSERT INTO `celery_taskmeta` (`task_id`, `status`, `result`, `date_done`, `traceback`) VALUES ('6e1c4e07-4274-42d2-ba1c-f610ccc89c03', 'PENDING', NULL, '2010-08-19 07:32:07', NULL)
          466 Query commit
100819 14:32:08   466 Query SELECT * FROM `celery_taskmeta` WHERE `celery_taskmeta`.`task_id` = '6e1c4e07-4274-42d2-ba1c-f610ccc89c03'
100819 14:32:15   467 Connect   root@localhost on test
          467 Query SET storage_engine=INNODB, time_zone=UTC
          467 Query SET NAMES utf8
          467 Query set autocommit=0
          467 Query SELECT * FROM `celery_taskmeta` WHERE `celery_taskmeta`.`task_id` = '6e1c4e07-4274-42d2-ba1c-f610ccc89c03'
          467 Query SELECT * FROM `celery_taskmeta` WHERE `celery_taskmeta`.`id` = 6  LIMIT 1
          467 Query UPDATE `celery_taskmeta` SET `task_id` = '6e1c4e07-4274-42d2-ba1c-f610ccc89c03', `status` = 'SUCCESS', `result` = 'STMKLg==', `date_done` = '2010-08-19 07:32:15', `traceback` = NULL WHERE `celery_taskmeta`.`id` = 6
          467 Query commit
          467 Quit  
100819 14:32:20   466 Query SELECT * FROM `celery_taskmeta` WHERE `celery_taskmeta`.`task_id` = '6e1c4e07-4274-42d2-ba1c-f610ccc89c03'

Reassuming ,

• Bug occours when Django ORM uses transactional database table for result backend, for example MySQL/InnoDB.
• Asking for result before task is completed (db SELECT) makes all consecutive SELECTS inside same transaction return same result (ready == False), despite worker has updated task status (SUCCESSFUL) from other, separate connection.
• I cannot see easy solution, if one want up-to-date result one should use non-transactional table for storing results, like MyISAM for MySQL.
• As many peoples are using transactional engines, it should be emhasized in documentation for celery.result.AsyncResult that asking for resul using ready() or result properties can return obsolete value, if transaction tables are used by database result backend.
• It's not a big deal in production systems, because if someone puts task into queue he rather doesn't need result in the same code block, so this is more likely terminal-man bug.

My proposition
if settings.DATABASE_SUPPORTS_TRANSACTIONS = True and inside_transaction=True and previous_call_to_result_returned_false:
raise Exception('Result is unknown - you're inside transaction')

Show warning if polling results with transaction isolation level repeatable-read on MySQL. Closed by b1fb37e. Thanks to zimnyz