Fix calculation of has_next_page in resolve_connection_from_cache

[SupImDos]

Description

The strawberry_django.relay.ListConnectionWithTotalCount.resolve_connection_from_cache method currently incorrectly attempts to determine has_next_page from the QuerySet._result_cache, as opposed to the cached records within it, resulting in an AttributeError being raised.

This PR ensures that has_next_page is determined via the last record in the QuerySet._result_cache (if applicable), so that we don't get an AttributeError

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Documentation

Issues Fixed or Closed by This PR

• Partially fixes Optimizer window pagination #613

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

Summary by Sourcery

Fix the calculation of has_next_page in resolve_connection_from_cache to prevent an AttributeError by using the last record in the QuerySet._result_cache.

Bug Fixes:

• Fix the calculation of has_next_page in resolve_connection_from_cache to prevent an AttributeError by correctly determining it from the last record in the QuerySet._result_cache.

[sourcery-ai]

Reviewer's Guide by Sourcery

This pull request fixes a bug in the resolve_connection_from_cache method of the ListConnectionWithTotalCount class in the strawberry_django.relay module. The bug was causing an AttributeError when attempting to determine the has_next_page value. The implementation has been updated to correctly calculate has_next_page using the cached records.

File-Level Changes

Change	Details	Files
Fixed calculation of has_next_page in resolve_connection_from_cache method	Removed incorrect calculation of has_next_page using result._strawberry_row_number Added new calculation for has_next_page using the last record in result Updated has_previous_page calculation to use result[0] instead of nodes[0] Added null checks to prevent errors when result is empty	strawberry_django/relay.py

---

Tips

• Trigger a new Sourcery review by commenting @sourcery-ai review on the pull request.
• Continue your discussion with Sourcery by replying directly to review comments.
• You can change your review settings at any time by accessing your dashboard:
  • Enable or disable the Sourcery-generated pull request summary or reviewer's guide;
  • Change the review language;
• You can always contact us if you have any questions or feedback.

[sourcery-ai]

Hey @SupImDos - I've reviewed your changes - here's some feedback:

Overall Comments:

• The fix looks good, but it would be beneficial to add test cases that reproduce the original issue and verify the fix. This will help prevent regression in the future.

Here's what I looked at during the review

• 🟡 General issues: 1 issue found
• 🟢 Security: all looks good
• 🟢 Testing: all looks good
• 🟢 Complexity: all looks good
• 🟢 Documentation: all looks good

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment to tell me if it was helpful.}

[sourcery-ai]

suggestion: Consider refactoring to improve robustness and performance

The current implementation could raise an IndexError if result is empty. Additionally, accessing result[0] and result[-1] multiple times may impact performance for larger lists. Consider refactoring like this:

if not result:
    has_previous_page = False
    has_next_page = False
else:
    first_item = result[0]
    last_item = result[-1]
    has_previous_page = first_item._strawberry_row_number > 1
    has_next_page = last_item._strawberry_row_number < last_item._strawberry_total_count

This approach handles the empty list case first and optimizes list access. It also maintains the corrected logic for has_next_page, which is an improvement over the previous version.

Suggested change

	has_previous_page = (
	nodes[0]._strawberry_row_number > 1 # type: ignore
	result[0]._strawberry_row_number > 1 # type: ignore
	if result
	else False
	)
	if not result:
	has_previous_page = False
	else:
	first_item = result[0]
	has_previous_page = first_item._strawberry_row_number > 1

[bellini666]

Ty! :)

Going to merge this even with the typing issue, as it is actually related to the newest release of pyright, and I even need to fix other unrelated code