Potential issue with field.queryset._result_cache persisting

[Luke Benstead]

Hi,

I'm currently working on porting Djangae to work with Django 1.11. As part of our test suite we run a number of Django tests which occasionally show up assumptions in the tests which don't hold true on the Google App Engine datastore, one common one is that IDs of objects created in tests will be sequential.

The last remaining test failure I have is a sporadic failure in tests.model_forms.tests.LimitChoicesToTests depending on the order in which the tests are run, either test_limit_choices_to_callable_for_fk_rel or test_limit_choices_to_callable_for_m2m_rel fails.

Here's one of those tests:

    def test_limit_choices_to_callable_for_fk_rel(self):
        """
        A ForeignKey can use limit_choices_to as a callable (#2554).
        """
        stumpjokeform = StumpJokeForm()
        self.assertSequenceEqual(stumpjokeform.fields['most_recently_fooled'].queryset, [self.threepwood])

The reason for the failure, is that immediately after StumpJokeForm() is instantiated (by the second of the two tests) the field's queryset._result_cache is already populated, holding an instance which no longer exists in the database as it was flushed between tests. It's as if the field's queryset is persisting between form instantiations, and between tests. It looks likely that this wouldn't show up in a normal Django test run because IDs are sequential there and so the IDs match when testing the assertion.

I'm always unsure about reporting bugs like this because Djangae has to do so much "weird" stuff to work it's possible it's something that we're doing but in this case I don't think it is. If it is something we're doing then I apologise in advance :)

[Tim Graham]

Could you bisect to find the Django commit where the behavior changed? If you could provide some code that reproduces the issue without having to setup the Djangae test suite, that would be great.

[Luke Benstead]

Unfortunately I don't have time to look into this too much, but I've attached a patch which updates the tests to check for an empty _result_cache after form instantiation. You can see that only one of the two tests fails (depending on order) because the _result_cache persists across tests.

[Tim Graham]

It's a regression in 6abd6c598ea23e0a962c87b0075aa2f79f9ead36 (#27563). I've reopened that ticket. Thanks for testing and reporting!