Opened 5 years ago

Closed 5 years ago

#16686 closed Bug (fixed)

Race condition in test_view_decorator()

Reported by: barry@… Owned by: nobody
Component: Core (Cache system) Version: 1.3
Severity: Normal Keywords:
Cc: Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by Aymeric Augustin)

test_view_decorator has this at the bottom:

        # And if we wait a few more seconds

        # the custom timeouot cache will miss
        response = other_with_timeout_view(request, '18')
        self.assertEqual(response.content, 'Hello World 18')

This fails on the Ubuntu build machines, although it succeeds on local builds. I got it to pass by bumping up the sleep to 5 seconds, but that's just a bandaid.

Judging from other sleeps in this test, I suspect there are more race conditions lurking.

Attachments (1)

16686.patch (679 bytes) - added by Aymeric Augustin 5 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 Changed 5 years ago by Russell Keith-Magee

Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset

Is this actually a race condition, or just an issue of being a bit more acommodating with timings? The test sets up the "other" cache with a 1 second expiry; the test has a 2 second sleep (line 1452) to make sure that it expires. There is a second sleep at line 1488; the final test you report is of a view with a 4 second timeout. This might be a bit of a lineball check -- technically, (2x2seconds + time to run other tests) should be > 4 seconds, but on a fast box, it might not evaluate like that. A 3 second sleep at line 1452 should be enough to ensure that the 4 second cache has expires (2 + 3 second sleep).

So - if I've understood the problem here, it isn't a race condition -- just a case where a fast box exposes the fact that 2+2+time for extra work may not be enough time to see the cache expire for the last test.

comment:2 Changed 5 years ago by Malcolm Tredinnick

I noticed yesterday that the CI install at was showing sporadic failures in the same area of tests. They were inconsistent, indicating there is something race-y going on there with timings, but my initial read didn't show up what it was.

comment:3 Changed 5 years ago by Aymeric Augustin

When the CI server is under heavy load (running 4 instances of the test suite in parallel), I've seen the following failure:

It isn't a race condition, it's just the machine that runs the tests that isn't "fast enough".

comment:4 Changed 5 years ago by Aymeric Augustin

Description: modified (diff)

Fixed formatting.

comment:5 Changed 5 years ago by Aymeric Augustin

Component: Testing frameworkCore (Cache system)
Has patch: set
Triage Stage: UnreviewedAccepted

I agree with Russel's theory. I think the best way to fix the problem is to set the cache expiry at 3 seconds (3 < 2 + 2). Patch attached.

Changed 5 years ago by Aymeric Augustin

Attachment: 16686.patch added

comment:6 Changed 5 years ago by Russell Keith-Magee

Triage Stage: AcceptedReady for checkin

comment:7 Changed 5 years ago by Jannis Leidel

Resolution: fixed
Status: newclosed

In [16728]:

Fixed #16686 -- Reduced time to wait for cache expiration in a test to alleviate race-condition-y effects.

Note: See TracTickets for help on using tickets.
Back to Top