Strange module behavior djangoql - django

Question

We use djangoql for easy search in our django admin panel.
The mixin DjangoQLSearchMixin has been added to some of our models in the admin panel.
And sometimes after deployment we get an error in the handler
application_name/model_name/introspect/
Error:
FieldDoesNotExist at /admin/user/user/introspect/
Model_name has no field named 'field_name'
After the reboot, the error disappears. The error cannot be reproduced locally.
Example:
"Address has no field named 'membership_requests'"
#admin.register(MembershipRequest, site=admin_site)
class MembershipRequestAdmin(DjangoQLSearchMixin, admin.ModelAdmin):
list_display = ("company", "user", "request_type", "status", "created_on", "updated_on")
class MembershipRequest(PureModelMixin):
company = models.ForeignKey("constrafor.Company", on_delete=models.CASCADE, related_name="membership_requests")
user = models.ForeignKey("user.User", on_delete=models.CASCADE, related_name="membership_requests")
address = models.OneToOneField(
"constrafor.Address",
related_name="membership_requests",
on_delete=models.CASCADE,
null=True,
blank=True,
help_text="FK to constrafor.Address",
)
code = models.ForeignKey(
"constrafor.Code", on_delete=models.SET_NULL, related_name="membership_requests", blank=True, null=True
)
company_name = models.CharField(null=True, blank=True, max_length=1000)
company_phone = models.CharField(null=True, blank=True, max_length=15)
company_type = models.CharField(max_length=15, choices=Company.COMPANY_TYPE_CHOICES)
is_needed_email_verification = models.BooleanField(default=False)
status = models.CharField(
max_length=8,
choices=MembershipRequestStatus.choices,
default=MembershipRequestStatus.pending,
)
request_type = models.CharField(
max_length=10,
choices=MembershipRequestType.choices,
default=MembershipRequestType.natural,
)

Answer 1

As I remarked in an earlier comment on your question, this seems to be a very tricky heisenbug. Not being able to properly debug it, as it cannot be reproduced, I found a way around it:
class CustomDjangoQLSchema(DjangoQLSchema):
def get_field_instance(self, model, field_name):
"""Some obscure heisenbug caused introspect requests to raise, rendering DjangoQL useless.`
This catch the exception and just skip the problematic field.
"""
try:
return super().get_field_instance(model, field_name)
except FieldDoesNotExist:
return None
If you use this Schema instead of the default you should be able to skip those failing fields.
UPDATE: Later I found out that the model that caused trouble was not registered with Django properly. It makes sense that a model that is not imported in models.__init__ but that does have a referral causes unexpected behaviour like this.