\n\nThis page has been machine-translated from the original page.
\n
While using a Python web application framework, I ran into the following error.
\nError details:\ndjango.core.management.base.SystemCheckError: SystemCheckError: System check identified some issues:\n\nERRORS:\nauth.User.groups: (fields.E304) Reverse accessor for 'User.groups' clashes with reverse accessor for 'User.groups'.\n HINT: Add or change a related_name argument to the definition for 'User.groups' or 'User.groups'.\nauth.User.user_permissions: (fields.E304) Reverse accessor for 'User.user_permissions' clashes with reverse accessor for 'User.user_permissions'.\n HINT: Add or change a related_name argument to the definition for 'User.user_permissions' or 'User.user_permissions'.\nmocrat_user.User.groups: (fields.E304) Reverse accessor for 'User.groups' clashes with reverse accessor for 'User.groups'.\n HINT: Add or change a related_name argument to the definition for 'User.groups' or 'User.groups'.\nmocrat_user.User.user_permissions: (fields.E304) Reverse accessor for 'User.user_permissions' clashes with reverse accessor for 'User.user_permissions'.\n HINT: Add or change a related_name argument to the definition for 'User.user_permissions' or 'User.user_permissions'.\n\nSystem check identified 4 issues (0 silenced).In the end, the cause was very basic: I had configured a custom user, but I had forgotten to set AUTH_USER_MODEL in Settings.
By the way, the fix was simply to add the following line to Settings.py.
AUTH_USER_MODEL = 'AppName.ClassName'
This error turned out to be a perfect sample for explaining the basics of troubleshooting, so in this article I will use it to explain a basic troubleshooting approach.
\nThis is a summary of basic ways to search and think when an error occurs.
\nNow then, the first step in troubleshooting is this: do not resist it—read the error message first.
\nCompilers and interpreters are very smart, so for minor problems, just reading the error message is often enough to resolve the issue.
\nFor example, in Python, you might see output like the following when an error occurs.
print(100 + \"Hello\")\n\nTraceback (most recent call last):\nFile \"stdin\", line 1, in module\nTypeError: unsupported operand type(s) for +: 'int' and 'str'First, right below the traceback, the location that caused the error is shown.
\nIn this example, it looks like the problem is on line 1.
Next, the reason for the error is written there.
\nTypeError: unsupported operand type(s) for +: 'int' and 'str'
\nSo it says that addition between int and str types is not supported.
In this example, just by reading that, you can tell that the error happened because 100 was not enclosed in quotation marks.
Now, let’s look again at the error message quoted at the beginning.
\nThere is a lot written there, but it does not mention the file name or the line number that caused the error.
\nAlso, the message SystemCheckError: System check identified some issues appears to be related to the cause, but it is not obvious what it means.
Error details:\n\ndjango.core.management.base.SystemCheckError: SystemCheckError: System check identified some issues:\n\nERRORS:\nauth.User.groups: (fields.E304) Reverse accessor for 'User.groups' clashes with reverse accessor for 'User.groups'.\n HINT: Add or change a related_name argument to the definition for 'User.groups' or 'User.groups'.\nauth.User.user_permissions: (fields.E304) Reverse accessor for 'User.user_permissions' clashes with reverse accessor for 'User.user_permissions'.\n HINT: Add or change a related_name argument to the definition for 'User.user_permissions' or 'User.user_permissions'.\nmocrat_user.User.groups: (fields.E304) Reverse accessor for 'User.groups' clashes with reverse accessor for 'User.groups'.\n HINT: Add or change a related_name argument to the definition for 'User.groups' or 'User.groups'.\nmocrat_user.User.user_permissions: (fields.E304) Reverse accessor for 'User.user_permissions' clashes with reverse accessor for 'User.user_permissions'.\n HINT: Add or change a related_name argument to the definition for 'User.user_permissions' or 'User.user_permissions'.\n\nSystem check identified 4 issues (0 silenced).At times like this, copy and paste the error message into a search engine.
\nIn that case, if you paste the whole thing, the search may not work well, so narrow it down to about one sentence.
\nAlso, try to use a part that does not include the names of files you created yourself.
\nIn this case, mocrat_user is the name of a file I created myself, so I made sure not to include that part in the search.
\nThis is because if the name of a custom file is included in the search terms, it can become noise and keep you from getting the results you want.
So let’s search for it.
\nFirst, I searched for SystemCheckError: System check identified some issues.
Let’s start by opening the top three articles.
\nThe contents were completely different.
\nIn the first article, SystemCheckError was caused by a failed MEDIA_URL setting, the second article was about missing admin.py settings, and the last one was about the migration mechanism.
From this, we can infer that SystemCheckError is probably not tied to one specific phenomenon, but is instead a generic message used for errors.
In the previous section, we learned that SystemCheckError seems to be output for a variety of different cases.
Because of that, I want to change the search terms, but before doing that I first need to narrow down the cause of the problem.
\nIn this case, because the error message does not include a file name, and based on the results of searching for SystemCheckError, I could guess that the cause might be a mistake in a configuration file or permissions.
Also, from the details of the error, it looks very likely that the problem is related to the User model.
\nSpecifically, there was a note about a Reverse accessor.
At this point, let’s search for the sentence Reverse accessor for 'User.groups' clashes with reverse accessor for 'User.groups'.
This time, all of the top results were articles about the same problem.
\nThat looked very promising.
That turned out to be the correct answer: even though I had defined a custom user, I had not written AUTH_USER_MODEL, so the models were conflicting.
This time, I was able to find the solution by searching for the error text itself, but another technique is to search by the error code.
\nIn particular, if you are using a minor system, searching by the error text may not hit the information you want.
\nIn that case, searching with the displayed error code can sometimes lead you to official documentation and other information related to the cause, so please give it a try.
In this case, the error code fields.E304 is displayed.
Because of that, the search term Django fields.E304 also found pages about the cause of this problem and how to fix it.
This time, I used Django troubleshooting as a theme to summarize basic knowledge such as reading error messages and how to search.
\nThere is surprisingly little information about the troubleshooting process itself, and it often feels like a field where a lot depends on individual instinct.
\nIf I find another good example in the future, I would like to introduce more detailed troubleshooting know-how, so please check back.
","fields":{"slug":"/note-how-to-troubleshoot-01-en","tagSlugs":["/tag/notes/","/tag/english/"]},"frontmatter":{"date":"2020-07-05","description":"In this article, I use this case study to explain the basics of troubleshooting.","tags":["Notes","English"],"title":"Troubleshooting Basics #1: Search the Error Message","socialImage":{"publicURL":"/static/dc4d8b7f8795f3c3d3489d9957d155f2/no-image.png"}}}},"pageContext":{"slug":"/note-how-to-troubleshoot-01-en"}},"staticQueryHashes":["251939775","401334301","825871152"]}