Home/ Questions/Q 6779975
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T16:27:05+00:00

On the web page, I get the following error: FieldError at /foo/bar/ Cannot resolve

  • 0

On the web page, I get the following error:

FieldError at /foo/bar/
Cannot resolve keyword 'foos' into field. Choices are: __unused__, [snip]

The problem code is

User.objects.filter(foos__name='bar')

When I run this in the shell, it works and I get a recordset:

>>> User.objects.filter(foos__name='bar')
[<User: JordanReiter>]

But on the webpage I get the exception above.

I’ve never run into this issue before and I wonder if I’m missing something?

Update

Based on doing a diff between the “Choices are: …” on the web and in the shell it appears there are 7 fields that are available in the shell that aren’t available if I do the query on the web. They appear to be ordinary ForeignKey fields pointing to User, with no difference from the other fields that work.

Tested So Far

  • INSTALLED_APPS are identical for both settings
  • runserver version also works (as would be expected)
  • User used is identical in both cases and is django.contrib.auth.models.User
  • related names for the shell’s User and the web app’s User are definitely different. User._meta.get_all_related_objects() in the shell displays around 7 more related fields than the if I dump that from the web app.
  • values for settings are also basically identical (one has the TEST_XYZ settings but those don’t affect anything)
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    This is only sort-of an answer. Turns out the reason that the field is not available is because all of the installed apps’ models do not correctly load in when the app is first compiled, so the app permanently believes certain fields don’t exist, even after they recognize the models for those fields do exist. It appears to be related to this earlier, equally confusing problem:

    SO: Internal Server error on the first request (and only the first request) after server reload

    Oh, and so how I fixed it was to change areas of code that imported the models that the web server couldn’t find on the first request. Somehow, omitting those meant that the server would recognize that the fields in question were present. Super weirdness!

    • 0