-
Notifications
You must be signed in to change notification settings - Fork 137
refactor: refactor BaseLlmFlow to make code more readable #310
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
praveen97uma
commented
Jul 31, 2025
- changed optional handling to be more functional
- moved one of the lambdas to a private method in the same class to reduce the size of the function
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Summary of Changes
Hello @praveen97uma, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request focuses on refactoring the BaseLlmFlow
class to enhance code readability and maintainability. The changes involve adopting a more functional approach for handling Optional
values and extracting a substantial inline lambda into a dedicated private method, thereby simplifying the main runLive
method.
Highlights
- Refactoring: Improved
Optional
handling within therunLive
method by replacingisPresent() ? get() : ...
with the more functional and conciseorElse(...)
pattern. - Code Organization: Extracted a large, complex lambda expression responsible for sending history data into a new private helper method named
sendHistory
. This significantly reduces the size and improves the readability of therunLive
method.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command>
or @gemini-code-assist <command>
. Below is a summary of the supported commands.
Feature | Command | Description |
---|---|---|
Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/
folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments or fill out our survey to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
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 refactors BaseLlmFlow
to improve readability by extracting a lambda into a private method and using a more functional style for handling Optional
values.
My review includes a critical fix for the Optional
handling, which currently uses orElse
instead of orElseGet
, potentially causing runtime exceptions and performance issues. I've also suggested improvements to the newly extracted method to reduce code duplication and improve formatting for better maintainability.
BaseLlm llm = agent.resolvedModel().model() | ||
.orElse(LlmRegistry.getLlm(agent.resolvedModel().modelName() | ||
.orElseThrow())); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The use of orElse
here can lead to a runtime exception and unnecessary work. orElse
evaluates its argument eagerly, meaning LlmRegistry.getLlm(...)
will be executed even if agent.resolvedModel().model()
is present.
If agent.resolvedModel().model()
is present but agent.resolvedModel().modelName()
is not, orElseThrow()
will throw a NoSuchElementException
, causing a crash.
To fix this, you should use orElseGet
, which evaluates its Supplier
argument lazily (only when the Optional
is empty).
BaseLlm llm = agent.resolvedModel().model() | |
.orElse(LlmRegistry.getLlm(agent.resolvedModel().modelName() | |
.orElseThrow())); | |
BaseLlm llm = agent.resolvedModel().model() | |
.orElseGet(() -> LlmRegistry.getLlm(agent.resolvedModel().modelName() | |
.orElseThrow())); |
private static Completable sendHistory(final InvocationContext invocationContext, final BaseLlmConnection connection, final LlmRequest llmRequestAfterPreprocess, final String eventIdForSendData) { | ||
Span sendDataSpan = | ||
Telemetry.getTracer().spanBuilder("send_data").startSpan(); | ||
try (Scope scope = sendDataSpan.makeCurrent()) { | ||
return connection | ||
.sendHistory(llmRequestAfterPreprocess.contents()) | ||
.doOnComplete( | ||
() -> { | ||
try (Scope innerScope = sendDataSpan.makeCurrent()) { | ||
Telemetry.traceSendData( | ||
invocationContext, | ||
eventIdForSendData, | ||
llmRequestAfterPreprocess.contents()); | ||
} | ||
}) | ||
.doOnError( | ||
error -> { | ||
sendDataSpan.setStatus( | ||
StatusCode.ERROR, error.getMessage()); | ||
sendDataSpan.recordException(error); | ||
try (Scope innerScope = sendDataSpan.makeCurrent()) { | ||
Telemetry.traceSendData( | ||
invocationContext, | ||
eventIdForSendData, | ||
llmRequestAfterPreprocess.contents()); | ||
} | ||
}) | ||
.doFinally(sendDataSpan::end); | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This new helper method is a good step towards improving readability. However, there are a few areas for improvement:
- Code Duplication: The
Telemetry.traceSendData(...)
call and its surroundingtry-with-resources
block are duplicated indoOnComplete
anddoOnError
. You can consolidate this logic usingdoOnEvent
to handle both success and error cases in one place. - Line Length: The method signature exceeds the standard 100-character line limit, making it harder to read. It should be wrapped for better readability.
- Formatting: The indentation for the chained method calls is inconsistent. Following a standard indentation style (e.g., +4 spaces for each level of continuation indent) would improve readability.
private static Completable sendHistory(
final InvocationContext invocationContext,
final BaseLlmConnection connection,
final LlmRequest llmRequestAfterPreprocess,
final String eventIdForSendData) {
Span sendDataSpan = Telemetry.getTracer().spanBuilder("send_data").startSpan();
try (Scope scope = sendDataSpan.makeCurrent()) {
return connection
.sendHistory(llmRequestAfterPreprocess.contents())
.doOnEvent(
(result, error) -> {
if (error != null) {
sendDataSpan.setStatus(StatusCode.ERROR, error.getMessage());
sendDataSpan.recordException(error);
}
try (Scope innerScope = sendDataSpan.makeCurrent()) {
Telemetry.traceSendData(
invocationContext,
eventIdForSendData,
llmRequestAfterPreprocess.contents());
}
})
.doFinally(sendDataSpan::end);
}
}
c6c51f1
to
acb6b7d
Compare
Hey, thank you for your contribution! Would you mind updating your branch? we've enabled formatting on build so this should help you get your files formatted & pass the CI. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes look good to me. Need the files to be formatted so CI passes. Once passing, good to merge these changes in