`--sync-once` on dev server still calls Launch Darkly

[ajworkos]

Is this a support request?

This is arguably not a bug and a feature instead, please update the status appropriately.

I was under the impression that when the --sync-once flag is present, there would be no communication with launch darkly.

In the original PR, however, CreateProject is still called when --sync-once is present, regardless of if there's a db file present or not. CreateProject will always call refreshExternalState here.

I'm curious if the original intent of --sync-once was to prevent any communication with launch darkly so that I could commit a DB file to source and have that be the source of truth to avoid communicating with LD in CI.

Describe the bug
Calling --sync-once when starting the dev server when a DB file is present still calls launch darkly

To reproduce
Add --sync-once when starting the dev server with a valid DB file.

Expected behavior
I would expect launch darkly APIs not to be called

Logs
If applicable, add any log output related to your problem.

CLI version
Latest

OS/platform
For instance, Ubuntu 16.04, Windows 10, or macOS 14.4.

Additional context
Add any other context about the problem here.

[dmashuda]

The original intent was to allow the dev server to always start with a source project/environment always, but to not override data in a project if --sync-once was passed.

This was mainly to support a containerized development environment:

• always running ldcli dev-server start --source ....
• with persistent volumes
  This allows the containers to be restarted without loosing state or the sync overriding state.

The fully-offline use-case is interesting though.

If you have a static set of flags that you want to snapshot and check in to git, have you considered using a yaml file?

[ajworkos]

I need the dev server, a yaml file won't do. I need the dev server because our E2E process uses it in CI and flips flags during tests are used across several services (that all need to be coordinated). I don't want to hit launch darkly cloud in CI.

What I ended up doing was actually creating a mounted volume in our repo so we could commit the SQLite file. Whenever we need to add new flags to our E2E tests, we sync it locally and then commit it. I start the dev server in CI without a project/environment, but mount the committed SQLite so it already has the data. This works for now, but is a bit of a pain.

What I'd really love to do is be able to be able to populate the dev server from a yaml file (or similar) so the file I commit to source control could be text instead of binary.

Also open to any other suggestions!

[dmashuda]

Thanks for giving more information detail about your use-case.

I think there is a relatively low effort change that we could make to allow --sync-once to check the local sqlitedb for the project/environment before calling LD. Would that improve your current process?

What I'd really love to do is be able to be able to populate the dev server from a yaml file (or similar) so the file I commit to source control could be text instead of binary.

Could you mind adding a separate issue for the enhancement request? I'll retain this issue for improving the existing --sync-once experience

[ajworkos]

Would that improve your current process?

Honestly, not a whole lot. I'd still have to commit the DB.

I'd argue that it would actually make it more intuitive. I was pretty confused for a while that --sync-once still called the cloud when my DB (with the project that I was specifying in it) was present until I looked into the code.