Skip to content
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

[FSSDK-11003] disposable service implementation #981

Merged

Conversation

junaed-optimizely
Copy link
Contributor

Summary

Making services disposable will allow the services to be disconnected from the repeater

Test plan

Test cases have been added

Issues

FSSDK-11003

@coveralls
Copy link

coveralls commented Jan 7, 2025

Coverage Status

coverage: 83.928% (-0.3%) from 84.24%
when pulling f2c3b5a on junaed/fssdk-11003-make-services-disposable-for-ssr
into 51e8c1a on master.

@junaed-optimizely junaed-optimizely marked this pull request as ready for review January 9, 2025 12:55
@junaed-optimizely junaed-optimizely requested a review from a team as a code owner January 9, 2025 12:55
Copy link
Contributor

@raju-opti raju-opti left a comment

Choose a reason for hiding this comment

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

added few comments

await expect(manager.onRunning()).resolves.not.toThrow();
expect(repeater.stop).toHaveBeenCalled();
});

Copy link
Contributor

Choose a reason for hiding this comment

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

can we also add tests that stops retrying to initialize after 5 failed attempts if disposable is true?

return;
}

if (this.datafile) {
this.handleNewDatafile(this.datafile, true);
}

if(this.disposable) {
Copy link
Contributor

Choose a reason for hiding this comment

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

instead can we override the makeDisposable method like this:

makeDisposable() {
  super.makeDisposable();
  this.datafileManager?.makeDisposable();
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah. Thanks for the suggestion!

@@ -89,6 +89,10 @@ export class PollingDatafileManager extends BaseService implements DatafileManag
return;
}

if(this.disposable) {
Copy link
Contributor

Choose a reason for hiding this comment

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

instead can we ovverride the makeDisposable method like this:

makeDisposable() {
  super.makeDisposable();
  this.initRetryRemaining = this.initRetryRemaining ?? 5;
}

odpManager?: OdpManager;
notificationCenter: DefaultNotificationCenter;
vuidManager?: VuidManager
disposable?:boolean;
Copy link
Contributor

Choose a reason for hiding this comment

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

NIT: space after ?:

odpManager?: OdpManager;
vuidManager?: VuidManager;
disposable?:boolean;
Copy link
Contributor

Choose a reason for hiding this comment

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

similar to above

expect(apiManager.sendEvents).toHaveBeenNthCalledWith(1, config, [event]);
expect(repeater.reset).toHaveBeenCalledTimes(1);
})

Copy link
Contributor

Choose a reason for hiding this comment

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

can we also add tests for repeater stop when disposable = true?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In the actual implementationrepeater.reset calls repeater.stop. But in the mock version of the repeater thats not the case. Whats your suggestion on that? Should I update the mock to support this ? (Not meaningful IMO).

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh I see we have assertions for repeater.reset here. We can ignore this comment

Copy link
Contributor

Choose a reason for hiding this comment

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

we can add a test to assert the repeater is not started, similar to eventProcessor

}

start(): void {
if (!this.isNew()) {
return;
}
if(this.disposable) {
Copy link
Contributor

Choose a reason for hiding this comment

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

can we override the makeDisposable method and do this inside that

@@ -39,12 +36,12 @@ describe('Optimizely', () => {

const notificationCenter = createNotificationCenter({ logger, errorHandler });

it('should pass ssr to the project config manager', () => {
it('should pass disposable option to the project config manager', () => {
Copy link
Contributor

Choose a reason for hiding this comment

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

it should pass the disposable option to eventProcessor and odpManager as well, can we modify this test to assert those as well?

this.retryConfig?.backoffProvider ||
(() => new ExponentialBackoff(DEFAULT_MIN_BACKOFF, DEFAULT_MAX_BACKOFF, 500)),
};
}
Copy link
Contributor

Choose a reason for hiding this comment

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

on old line 245 below, we should check disposable before starting failedEventRepeater.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So we will not start the "failedEventRepeater" if event processor is disposable?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes

expect(eventDispatcher.dispatchEvent.mock.calls[0][0]).toEqual(buildLogEvent(events));
expect(dispatchRepeater.reset).toHaveBeenCalledTimes(1);
});

Copy link
Contributor

Choose a reason for hiding this comment

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

can we add tests for the following as well when disposable

  1. FailedEventRepeater is not started
  2. dispatchRepeater is not started
  3. maxRetry is limited

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Regarding your number 2 - Current logic is - dispatchRepeater starts, dispatch immediately and then stops. Isn't this expected ? Or am I missing something here ?

Copy link
Contributor

Choose a reason for hiding this comment

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

according to the refactored logic in this PR, if batchSize == 1, dispatch repeater should never start. It will immediately dispatch the event, the repeater start is in the else branch

Copy link
Contributor

@raju-opti raju-opti left a comment

Choose a reason for hiding this comment

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

one small comment

this.failedEventRepeater?.start();

if(!this.disposable) {
this.dispatchRepeater.start();
Copy link
Contributor

Choose a reason for hiding this comment

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

we should not start the dispatchRepeater here. It will be started when an event is queued.

Copy link
Contributor Author

@junaed-optimizely junaed-optimizely Jan 13, 2025

Choose a reason for hiding this comment

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

Oh right! My bad! I guess , I am still wrapping my head around this service pattern. Adding something somewhere, forget to remove from somewhere. Appologies

Copy link
Contributor

@raju-opti raju-opti left a comment

Choose a reason for hiding this comment

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

LGTM

@junaed-optimizely junaed-optimizely merged commit 92ab2a7 into master Jan 13, 2025
11 of 18 checks passed
@junaed-optimizely junaed-optimizely deleted the junaed/fssdk-11003-make-services-disposable-for-ssr branch January 13, 2025 15:28
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.

3 participants