Changes between Initial Version and Version 1 of Ticket #32831, comment 15


Ignore:
Timestamp:
Apr 13, 2024, 1:24:08 PM (8 months ago)
Author:
Simon Charette

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #32831, comment 15

    initial v1  
    1 I get a sense that a lot of these failures are due to tests using their same global store at the same time as Chris pointed out. A clear sign of that is `cache.clear` is being called at `setUp` time.
     1I get a sense that a lot of these failures are due to tests using their same global store at the same time as Chris pointed out. A strong supporting signal of that is `cache.clear` is being called at `setUp` time which (e.g. in the case of memcached backend tests) could cause keys to be unexpectedly evicted.
    22
    33A solution here could be to run these tests cases in they own separate key space (e.g. with a cache key prefix or with two distinct memcached instances) or to serialize them to ensure that no tests share the same resource (e.g. using a `multiprocessing.lock` acquired in `setUp` and released in `tearDown`).
Back to Top