Skip to content

fix: increase channel in LO to 10% of the max results#2735

Merged
Vic-Dev merged 7 commits intomainfrom
fix/increase-lo-chan
Oct 16, 2025
Merged

fix: increase channel in LO to 10% of the max results#2735
Vic-Dev merged 7 commits intomainfrom
fix/increase-lo-chan

Conversation

@Vic-Dev
Copy link
Contributor

@Vic-Dev Vic-Dev commented Oct 8, 2025

Description

What problem is being solved?

The buffer size for LO is quite low for the default max results size of 1000. Increased the buffer to be 10% of the max results, capping the max results at 1000, and mining the buffer size to 10.

References

Review Checklist

  • I have clicked on "allow edits by maintainers".
  • I have added documentation for new/changed functionality in this PR or in a PR to openfga.dev [Provide a link to any relevant PRs in the references section above]
  • The correct base branch is being used, if not main
  • I have added tests to validate that the change in functionality is working as expected

Summary by CodeRabbit

  • Bug Fixes

    • Improved stability and performance when listing objects by increasing internal request buffering based on expected result size. This reduces bottlenecks, mitigates timeouts, and delivers smoother, faster results—especially for larger listings.
  • Documentation

    • Updated the changelog to record the fix for list object buffering under the Unreleased section.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Oct 8, 2025

Important

Review skipped

Auto incremental reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Walkthrough

Adjusts list object buffering by computing channel capacity dynamically based on max results, and documents the change in the changelog.

Changes

Cohort / File(s) Summary
Changelog update
CHANGELOG.md
Added Unreleased -> Fixed entry noting LO request buffer size is now 10% of max results or at least 10 (ref PR #2735).
ListObjects buffering logic
pkg/server/commands/list_objects.go
In ListObjectsQuery.evaluate, replaced fixed channel buffer (1) with dynamic capacity: default 10, or max(10, maxResults/10) when maxResults < 1000; affects reverseExpandResultsChan sizing only.

Sequence Diagram(s)

sequenceDiagram
  autonumber
  participant C as Client
  participant S as Server: ListObjectsQuery
  participant R as ReverseExpand Worker

  C->>S: ListObjects request
  Note over S: Compute bufferSize = 10 by default<br/>If maxResults set and <1000:<br/>bufferSize = max(10, maxResults/10)
  S->>S: Create reverseExpandResultsChan(bufferSize)
  S->>R: Start reverse expand processing
  R-->>S: Send ReverseExpandResult (buffered)
  S-->>C: Stream results (until done)
  Note over S,R: Backpressure governed by dynamic buffer
Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Suggested reviewers

  • justincoh
  • senojj
  • adriantam

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)
Check name Status Explanation
Docstring Coverage ✅ Passed No functions found in the changes. Docstring coverage check skipped.
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check ✅ Passed The title clearly and concisely describes the primary change by stating that the list-objects channel size is increased to 10% of the maximum results. It follows conventional prefixing for a bug fix and directly reflects the implementation details without unnecessary noise. This makes it easy for reviewers to understand the main purpose at a glance.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@codecov
Copy link

codecov bot commented Oct 8, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.08%. Comparing base (293893b) to head (70cb5c3).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2735      +/-   ##
==========================================
- Coverage   90.12%   90.08%   -0.04%     
==========================================
  Files         144      144              
  Lines       19928    19906      -22     
==========================================
- Hits        17959    17931      -28     
- Misses       1493     1502       +9     
+ Partials      476      473       -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@Vic-Dev Vic-Dev force-pushed the fix/increase-lo-chan branch from 5ff5bac to 05a076b Compare October 10, 2025 20:18
@Vic-Dev Vic-Dev marked this pull request as ready for review October 10, 2025 20:19
@Vic-Dev Vic-Dev requested a review from a team as a code owner October 10, 2025 20:19
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
CHANGELOG.md (1)

12-12: Clarify the buffer sizing logic in the changelog.

The changelog states the buffer is "10% of the max results or 10", but the implementation only applies the 10% sizing when listObjectsMaxResults < 1000. For listObjectsMaxResults >= 1000 or unlimited (0), the buffer remains fixed at 10. Consider updating the changelog to reflect this threshold.

Apply this diff to provide a more accurate description:

-- Increase the buffer size for LO requests to be 10% of the max results returned or 10. [#2735](https://github.com/openfga/openfga/pull/2735)
+- Increase the buffer size for LO requests to 10% of the max results (minimum 10) when max results is below 1000, otherwise 10. [#2735](https://github.com/openfga/openfga/pull/2735)
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 1e79eba and 7a92b27.

📒 Files selected for processing (2)
  • CHANGELOG.md (1 hunks)
  • pkg/server/commands/list_objects.go (1 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
pkg/server/commands/list_objects.go (1)
pkg/server/commands/reverseexpand/reverse_expand.go (1)
  • ReverseExpandResult (219-222)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
  • GitHub Check: go-bench
  • GitHub Check: docker-tests
  • GitHub Check: tests
  • GitHub Check: Dry Run GoReleaser
  • GitHub Check: Analyze (go)
🔇 Additional comments (1)
pkg/server/commands/list_objects.go (1)

324-332: Verify the buffer size discontinuity at the 1000 threshold.

There's a sharp discontinuity in the buffer sizing logic:

  • For maxResults = 999: buffer = 99
  • For maxResults = 1000: buffer = 10

This 10x drop might not be intentional. Consider whether the threshold of 1000 is the right approach, or if a capped scaling would be better.

If the discontinuity is intentional (e.g., to prevent excessive memory usage), consider adding a comment explaining the rationale. Otherwise, you might want to smooth the logic with a cap:

 bufferSize := 10
-if q.listObjectsMaxResults > 0 && q.listObjectsMaxResults < 1000 {
-	bufferSize = int(q.listObjectsMaxResults / 10) // 10% of max results
-	if bufferSize < 10 {
-		bufferSize = 10
-	}
+if q.listObjectsMaxResults > 0 {
+	calculatedSize := int(q.listObjectsMaxResults / 10)
+	if calculatedSize > 10 {
+		bufferSize = min(100, calculatedSize) // cap at 100 to prevent excessive memory
+	}
 }

@Vic-Dev Vic-Dev changed the title fix: attempt to increase the channel size fix: increase channel in LO to 10% of the max results Oct 10, 2025
@poovamraj
Copy link
Contributor

@claude

@github-actions
Copy link
Contributor

github-actions bot commented Oct 13, 2025

Claude encountered an error —— View job


I'll analyze this and get back to you.

1 similar comment
@github-actions
Copy link
Contributor

github-actions bot commented Oct 13, 2025

Claude encountered an error —— View job


I'll analyze this and get back to you.

@poovamraj
Copy link
Contributor

@claude

@github-actions
Copy link
Contributor

github-actions bot commented Oct 13, 2025

Claude finished @poovamraj's task —— View job


Review Progress

  • Read PR diff and understand changes
  • Read project architecture documentation
  • Perform code quality review
  • Perform security review
  • Perform performance review
  • Provide overall assessment

Overall Assessment

❌ The PR contains logic that doesn't match its description and CHANGELOG. The implementation calculates bufferSize = max(10, min(maxResults, 1000) / 10), resulting in a maximum buffer of 100 (not 10) when maxResults >= 1000. Either the code should be updated to match the documented intent, or the PR description and CHANGELOG should be updated to reflect the actual behavior (buffer size ranges from 10 to 100).


View Job

@Vic-Dev Vic-Dev merged commit 19b19f5 into main Oct 16, 2025
22 checks passed
@Vic-Dev Vic-Dev deleted the fix/increase-lo-chan branch October 16, 2025 14:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants