-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Cloud: fix provider syncing #7603
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
Conversation
ClineProvider creation was moved before CloudService which broke the old way of doing things.
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.
Thank you for your contribution! I've reviewed the changes and this is a clean fix for the race condition between ClineProvider and CloudService initialization. The approach of deferring initialization until CloudService is ready is sound. I have some suggestions for improvement below.
|
|
||
| if (CloudService.hasInstance()) { | ||
| CloudService.instance.off("settings-updated", this.handleCloudSettingsUpdate) | ||
| CloudService.instance.on("settings-updated", this.handleCloudSettingsUpdate) |
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.
Is this intentional? The method removes and then immediately re-adds the "settings-updated" event listener (lines 321-322). This could lead to duplicate listeners if initializeCloudProfileSyncWhenReady() is called multiple times. Consider tracking whether a listener is already registered or using a flag to prevent duplicate registrations.
| /** | ||
| * Initialize cloud profile synchronization when CloudService is ready | ||
| * This method is called externally after CloudService has been initialized | ||
| */ |
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 enhancing this comment to explain why this deferred initialization pattern is necessary. For example: 'Initialize cloud profile synchronization when CloudService is ready. This method is called externally after CloudService has been initialized to handle the race condition where ClineProvider may be created before CloudService.'
| await provider.initializeCloudProfileSyncWhenReady() | ||
| } catch (error) { | ||
| outputChannel.appendLine( | ||
| `[CloudService] Failed to initialize cloud profile sync: ${error instanceof Error ? error.message : String(error)}`, |
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 error is caught and logged, but should the extension take any recovery action here? If cloud profile sync is critical for certain features, users might want to know if it fails during startup. Consider whether a user notification would be appropriate for this failure case.
ClineProvidercreation was moved beforeCloudServicewhich broke the old way of doing things.Important
Fix cloud profile synchronization in
ClineProviderby deferring initialization untilCloudServiceis ready.ClineProvider, deferinitializeCloudProfileSync()untilCloudServiceis ready.initializeCloudProfileSyncWhenReady()inClineProviderto handle sync afterCloudServiceinitialization.extension.ts, callinitializeCloudProfileSyncWhenReady()afterCloudServiceis initialized.This description was created by
for b1f2608. You can customize this summary. It will automatically update as commits are pushed.