Problem with getattr Handling in _resolve_lookup Method

[Mohammad Salehi]

Hello,

While working on issue #35673, which deals with handling request.GET when the number of query parameters exceeds the limit set in settings.DATA_UPLOAD_MAX_NUMBER_FIELDS, I discovered another problem with the _resolve_lookup method in the Variable class inside template/base.py. When request.GET encounters an error, it causes issues in the _resolve_lookup method. Specifically, when the code tries to access GET and uses the getattr function, this function does not handle errors properly, which leads to further problems in the system.

I believe there are two solutions: or the getattr function should be modified to handle errors correctly, or the underlying cause of the error in getattr should be addressed. It would be best to discuss this with the other team members to determine the best approach and then implement the necessary changes.

[Sarah Boyce]

Would you mind writing a test demonstrating the issue you think should be solved here? Or could you provide a minimal reproducible example, or a stack trace?

[Mohammad Salehi]

Thanks for your response. I understand the need for a clear display of the issue. The problem I discovered is directly related to the test you wrote for issue #35673.

In the original code, there was an infinite loop caused by the way request.GET was accessed. In views/debug.py:

c["request_GET_items"] = self.request.items()

I resolved this issue by modifying the code to:

c["request_GET_items"] = self.request.META.get("QUERY_STRING", "")

This fix breaks the loop and allows the program to continue execution. However, after this change, another issue became apparent in the _resolve_lookup method when the code encounters GET during the lookup process.

Specifically, the issue arises here in template/base.py in line 893:

current = getattr(current, bit)

When bit is GET, getattr fails to handle it correctly, leading to an error. This seems to be the root cause of the problem that needs addressing.

I believe that fixing the loop in the original test (issue #35673) will allow us to reproduce on this getattr error. It would be great to discuss with the team whether we should modify getattr to handle this scenario better or if we need to address the issue in another part of the code.

It way is you see this error.

[Sarah Boyce]

I think we are still missing a clear way to replicate this issue on main - a test or a minimal project to replicate the issue is needed.

This currently describes a scenario that is dependent on how another ticket is handled, and so it is not clear whether this needs a new ticket or can be handled in the existing ticket #35673. Ideally, an external person can read the ticket and understand it without being sent to another ticket