Skip to content

fix: fix session budget penalty logic#13857

Open
mutianf wants to merge 1 commit into
googleapis:mainfrom
mutianf:budget
Open

fix: fix session budget penalty logic#13857
mutianf wants to merge 1 commit into
googleapis:mainfrom
mutianf:budget

Conversation

@mutianf

@mutianf mutianf commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

Remove the early break when draining creation failures pool and update the logic when returning the next available budget. The list is not strictly increasing order of the timestamps. Updates to the penalty duration can change the orders of the timestamps in the list:

  • An older failure might have a long expiration time (e.g., 10 seconds in the future) at index 0.
  • Update config shortens the duration to 2 seconds.
  • A newer failure, using the updated shorter penalty, might have an earlier expiration time (e.g., 2 seconds in the future) at index 1.

@mutianf
mutianf requested review from a team as code owners July 22, 2026 02:41

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Code Review

This pull request updates 'SessionCreationBudget.java' to use 'Collections.min()' for retrieving the earliest timestamp from 'delayedCreationTokens', removing the assumption that the list is sorted and deleting the early-exit optimization in 'drainCreationFailures()'. The reviewer suggests using a 'PriorityQueue' instead of a 'List' to optimize finding the minimum element from O(N) to O(1) and improve overall performance.

}

return delayedCreationTokens.get(0);
return Collections.min(delayedCreationTokens);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

medium

While Collections.min() correctly finds the earliest timestamp, it has a time complexity of O(N) for a List, where N can be up to maxConcurrentRequests (default 1000). This could become a performance bottleneck if getNextAvailableBudget() is called frequently.

Consider using a java.util.PriorityQueue for delayedCreationTokens. This would make getNextAvailableBudget() an O(1) operation (peek()), and addCreationFailure() an O(log N) operation. drainCreationFailures() could also be implemented more efficiently by repeatedly polling expired items from the head of the queue (O(k*logN) where k is the number of expired items).

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.

1 participant