-
Notifications
You must be signed in to change notification settings - Fork 94
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
feat: handled unknown dialect for cloud #1450
Conversation
WalkthroughThe pull request introduces modifications to the Changes
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
private async retryOnce() { | ||
if (this.firstRun) { | ||
return; | ||
} | ||
this.firstRun = true; | ||
this.findAdapterType(); |
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.
@mdesmet, should we add a telemetry event for retry and maybe for failure as well?
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 requested. Reviewed everything up to eaaa4c9 in 32 seconds
More details
- Looked at
32
lines of code in1
files - Skipped
0
files when reviewing. - Skipped posting
2
drafted comments based on config settings.
1. src/dbt_client/dbtCloudIntegration.ts:1078
- Draft comment:
Consider usingawait
withthis.retryOnce()
in the setTimeout callback to ensure asynchronous operations are completed before proceeding. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable:
The comment suggests a change that is not necessary for the current implementation. ThesetTimeout
function is used to delay the execution ofretryOnce
, and there is no need to wait for its completion in this context. The suggestion to useawait
is not applicable here, as it would not change the behavior of the code in a meaningful way. The comment does not provide strong evidence of a required code change.
I might be overlooking a scenario where awaitingretryOnce
could be beneficial, such as if subsequent code depends on its completion. However, the current context does not indicate such a dependency.
The current implementation does not show any dependency on the completion ofretryOnce
before proceeding. The use ofsetTimeout
is to retry after a delay, and awaiting it would not provide any additional benefit.
Delete the comment as it suggests an unnecessary change. The use ofawait
in this context does not provide any benefit, and the current implementation is sufficient.
2. src/dbt_client/dbtCloudIntegration.ts:1035
- Draft comment:
Add a return type to thefindAdapterType
function signature for better clarity and refactoring ease.
private async findAdapterType(): Promise<void> {
- Reason this comment was not posted:
Comment was on unchanged code.
Workflow ID: wflow_mJHeoyTJUATS32AR
Want Ellipsis to fix these issues? Tag @ellipsis-dev
in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet
mode, and more.
return; | ||
} | ||
this.firstRun = true; | ||
this.findAdapterType(); |
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.
Consider using await
with this.findAdapterType()
in retryOnce
to ensure asynchronous operations are completed before proceeding.
@@ -1023,6 +1023,15 @@ export class DBTCloudProjectIntegration | |||
} | |||
} | |||
|
|||
private firstRun = false; | |||
private async retryOnce() { |
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.
Add a return type to the retryOnce
function signature for better clarity and refactoring ease.
private async retryOnce() { | |
private async retryOnce(): Promise<void> { |
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.
private firstRun = false; | ||
private async retryOnce() { | ||
if (this.firstRun) { | ||
return; | ||
} | ||
this.firstRun = true; | ||
this.findAdapterType(); | ||
} |
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.
🛠️ Refactor suggestion
Refine the retryOnce
method for clarity and correctness
-
The variable
firstRun
is used to prevent multiple retries in theretryOnce
method. However, the namefirstRun
may be misleading, as it suggests tracking the first execution of the entire process, whereas it's actually used to ensure that the retry logic occurs only once. Consider renaming it tohasRetried
orretryAttempted
to improve code readability. -
The
retryOnce
method is declared asasync
, but it doesn't useawait
when callingthis.findAdapterType()
. IffindAdapterType
is an asynchronous function, you might want toawait
its completion to handle any potential errors. Alternatively, if you don't need to wait forfindAdapterType()
to complete, consider removing theasync
keyword fromretryOnce
.
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.
👍 Looks good to me! Incremental review on fdfa089 in 22 seconds
More details
- Looked at
33
lines of code in1
files - Skipped
0
files when reviewing. - Skipped posting
3
drafted comments based on config settings.
1. src/dbt_client/dbtCloudIntegration.ts:1036
- Draft comment:
Consider usingawait
when callingfindAdapterType()
inretryOnce()
to ensure the method completes before proceeding. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable:
The comment is suggesting a change that has already been implemented in the code. Theawait
keyword is already used withfindAdapterType()
in theretryOnce()
function. Therefore, the comment is not necessary.
I might be missing some context about why the comment was made, but based on the current code, the suggestion is already implemented.
The code clearly shows thatawait
is used, so the comment is redundant regardless of any additional context.
The comment should be deleted because the suggested change is already implemented in the code.
2. src/dbt_client/dbtCloudIntegration.ts:1046
- Draft comment:
Consider usingawait
when callingfindAdapterType()
inretryOnce()
to ensure the method completes before proceeding. - Reason this comment was not posted:
Marked as duplicate.
3. src/dbt_client/dbtCloudIntegration.ts:1046
- Draft comment:
Consider using early returns in thefindAdapterType
function to reduce nesting and improve readability. - Reason this comment was not posted:
Comment was on unchanged code.
Workflow ID: wflow_5aJPw3cXyY1IFCZe
You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet
mode, and more.
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.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
src/dbt_client/dbtCloudIntegration.ts (1)
1031-1044
: Good addition of retry mechanism, but consider usingawait
.The
retryOnce
method is a good addition to improve the reliability of adapter type detection. The use of a flag to prevent multiple retries is a smart approach.However, since the method is declared as
async
, consider usingawait
when callingthis.findAdapterType()
:private async retryOnce() { if (this.firstRun) { return; } this.firstRun = true; const startTime = Date.now(); - this.findAdapterType(); + await this.findAdapterType(); const elapsedTime = Date.now() - startTime; this.telemetry.sendTelemetryEvent("cloudFindAdapterTypeElapsedTime", { elapsedTime: elapsedTime.toString(), retry: "true", }); }This ensures that the timing measurement accurately reflects the duration of
findAdapterType()
.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
- src/dbt_client/dbtCloudIntegration.ts (3 hunks)
🔇 Additional comments (1)
src/dbt_client/dbtCloudIntegration.ts (1)
241-246
: LGTM: Improved performance tracking for adapter type detection.The addition of timing measurement for
findAdapterType()
is a good improvement. It enhances observability and can help in identifying performance issues related to adapter type detection.
if (!this.adapterType) { | ||
setTimeout(() => { | ||
this.retryOnce(); | ||
}, 5000); | ||
} |
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.
🛠️ Refactor suggestion
Consider enhancing the retry mechanism.
The addition of a retry mechanism for adapter type detection is a good improvement for handling transient issues. However, there are a few points to consider:
-
The current implementation might lead to multiple concurrent retries if
findAdapterType
is called multiple times in quick succession. Consider using a class-level flag to prevent this. -
There's no upper limit on the number of retries, which could lead to infinite retries in case of persistent issues. Consider implementing a maximum retry count.
-
The retry is triggered in the
findAdapterType
method, but the actual retry logic is inretryOnce
. This separation might make the flow harder to follow.
Here's a suggestion to address these points:
private retryCount = 0;
private readonly MAX_RETRIES = 3;
private isRetrying = false;
private async findAdapterType() {
// ... existing code ...
if (!this.adapterType && this.retryCount < this.MAX_RETRIES && !this.isRetrying) {
this.retryCount++;
this.isRetrying = true;
setTimeout(async () => {
await this.retryOnce();
this.isRetrying = false;
}, 5000);
}
}
This approach limits the number of retries, prevents concurrent retries, and keeps the retry logic within the findAdapterType
method for better clarity.
Overview
Problem
Describe the problem you are solving. Mention the ticket/issue if applicable.
Solution
Describe the implemented solution. Add external references if needed.
Screenshot/Demo
A picture is worth a thousand words. Please highlight the changes if applicable.
How to test
Checklist
README.md
updated and added information about my changeImportant
Adds retry mechanism in
DBTCloudProjectIntegration
to handle unknown adapter types by retrying adapter type detection once.retryOnce()
method inDBTCloudProjectIntegration
to retry fetching adapter type if unknown.findAdapterType()
to callretryOnce()
ifadapterType
is not set.firstRun
boolean to ensureretryOnce()
is only executed once.findAdapterType()
andretryOnce()
inDBTCloudProjectIntegration
.This description was created by for fdfa089. It will automatically update as commits are pushed.
Summary by CodeRabbit