bitwise or on queryset fails when using exlude over manytomany

[harm]

description

In the case below, when doing a bitwise or of 2 querysets, the results fails silently.

An item that should be in the result, is not.

steps to reproduce

run the following test case

models.py

from django.db import models

class Poll(models.Model):
    question = models.CharField(max_length=200)
    choices = models.ManyToManyField('Choice', related_name='polls')

        
class Choice(models.Model):
    choice_text = models.CharField(max_length=200)
    votes = models.IntegerField(default=0)

tests.py

from django.test import TestCase
    
from models import Poll, Choice
    
class SimpleTest(TestCase):
    def test_or(self):
        """
        Tests that querysets can be or-ed
        """
        p = Poll.objects.create()

        c1 = Choice.objects.create()
        c2 = Choice.objects.create()
        c3 = Choice.objects.create()


        qs1 = Poll.objects.exclude(choices__in=[c1, c2])
        qs2 = Poll.objects.filter(choices__in=[c3])

        self.assertTrue(p in qs1)
        self.assertFalse(p in qs2)

        # here is the bug,  p is in qs1, but not in the orred result
        self.assertTrue(p in (qs1|qs2))

result

Test fails

======================================================================
FAIL: test_or (poll.tests.SimpleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "mysite/poll/tests.py", line 31, in test_or
    self.assertTrue(p in (qs1|qs2))
AssertionError: False is not True

expected result

testcase passes

version

found on 1.4.3, same problem exists in 1.5.0

[Anssi Kääriäinen <akaariai@…>]

In 80e68ee2ffb44d90c66b48e2db18ec4e16c025b4:

Added tests for already fixed #20101

The ticket dealt with a case where one query had .exclude() that
produced a subquery, the other query had a join to the same model that
was subqueried in the first query. This was already fixed in master, so
only test added.

[Anssi Kääriäinen]

This has been fixed in master, I don't know which commit contains the fix.

Backpatching the fix would likely require a lot of changes to stable/1.5.x. Even if a simple fix were found, the backpatching rules do not support backpatching as this isn't a regression nor critical failure in 1.5.