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

Event queue not fully cleaned up on close #774

Open
walmor-rematter opened this issue Mar 21, 2024 · 4 comments
Open

Event queue not fully cleaned up on close #774

walmor-rematter opened this issue Mar 21, 2024 · 4 comments

Comments

@walmor-rematter
Copy link

I'm integrating our backend with @devcycle/nodejs-server-sdk and having a very particular issue related to hot reloading and needing to initialize the lib multiple times by calling initializeDevCycle.

We have a custom hot reload mechanism that does not shut down the process. To summarize, it simply rebuilds, clears caches, and restarts the express app on the fly. Thus, imported packages (node_modules) are not reloaded after changing a file, making it very fast. However, when the app restarts and calls the initializeDevCycle for the second time, we get this error:

Event Queue already exists for sdkKey: ${sdkKey} you can only initialize the DevCycle SDK once per sdkKey

We're calling devCycleClient.close() when the app shuts down but that doesn't solve the problem. Looking at the code, I can see that the close() method on the DevCycleClient calls the cleanup method on the EventQueue but that's not enough. I believe that a potential solution is to also call the cleanupEventQueue(sdkKey) method when closing the client, but I'm not sure if that has any drawbacks.

That's what I'm doing to workaround the problem for now, essentially this:

import { getBucketingLib } from '@devcycle/nodejs-server-sdk/src/bucketing';

export const closeFeatureFlagsClient = async () => {
  if (devCycleClient) {
    await devCycleClient.close();
  }
  
  getBucketingLib().cleanupEventQueue(DEV_CYCLE_SERVER_KEY);
};

It works, but I believe the cleanupEventQueue method was only intended to be used internally.

Another solution I can see is to add an option to the initializeDevCycle method that would allow us to continue normally even if the queue was already created, or something like that.

@linear linear bot changed the title Event queue not fully cleaned up on close Rematter: Event queue not fully cleaned up on close Mar 21, 2024
@linear linear bot changed the title Rematter: Event queue not fully cleaned up on close Event queue not fully cleaned up on close Mar 21, 2024
@cdruxerman
Copy link

@walmor-rematter I'll have our team look into this for you

@linear linear bot added rematter and removed rematter labels Mar 21, 2024
@cdruxerman
Copy link

Also @walmor-rematter sorry for all the name and label changes. We just started trying out the github/linear sync and I wasn't expecting those

@elliotCamblor
Copy link
Contributor

elliotCamblor commented Mar 21, 2024

Hey @walmor-rematter! I believe the reason we don't fully cleanup the event queue on close is because there are cases where new events can be added to the queue after the flushEvents() call in the close method, but which get picked up in the flush that runs on an interval.

That being said, we've discussed in the past that we would like to be able initializing the sdk multiple times for use cases like your own. I'll bring it back to the team to discuss and we will keep you posted on how we decide to handle it!

In the meantime, if manually cleaning up the event queue is working for you then I would suggest going forward with that.

Thanks very much for your feedback and let me know if you have any other questions!

@walmor-rematter
Copy link
Author

Hey @elliotCamblor,

Got it, well, if fully cleaning up the queue on close is not possible then, yes, allowing us to initialize the SDK multiple times would be very helpful.

I'll keep my workaround for now until we have a better solution.

Thank you for the quick reply!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants