devcyclehq / js-sdks Goto Github PK

Sometime after version 1.14, something changed that broke the package.
I get this error during bundling:

Unable to resolve "class-validator" from "node_modules\@devcycle\react-native-expo-client-sdk\node_modules\@devcycle\types\index.cjs.js"

If I downgrade to 1.14, I no longer get the error.
I'm using Expo SDK 50.

I'm seeing Error initializing DevCycle: TypeError: Converting circular structure to JSON error when attempting to provide a custom logger to the initializeDevCycle function. This error is seemingly related to winston as swapping winston with a custom logger that uses console.log does not throw this error.

Package versions

@devcycle/nodejs-server-sdk: 1.33.2
@devcycle/types: 1.16.0
winston: 3.13.1

Test code

import { DVCVariable, initializeDevCycle } from '@devcycle/nodejs-server-sdk';
import { DVCLogger } from '@devcycle/types';
import winston, { Logger } from 'winston';

export const logger: winston.Logger = winston.createLogger({
  format: winston.format.combine(
    winston.format.metadata(),
    winston.format.errors({ stack: true }),
    winston.format.timestamp(),
    winston.format.json()
  ),
  transports: [
    new winston.transports.Console({
      handleExceptions: true,
      level: 'debug'
    })
  ],
  exitOnError: false
});

export class CustomLogger implements DVCLogger {
  constructor(private logger: Logger) {}

  error(message: string, error?: unknown): void {
    this.logger.error(message, {
      error
    });
  }
  warn(message: string): void {
    this.logger.warn(message);
  }
  info(message: string): void {
    this.logger.info(message);
  }
  debug(message: string): void {
    this.logger.debug(message);
  }
}

(async () => {
  await initializeDevCycle('dvc_server_fake-key', {
    logLevel: 'debug',
    logger: new CustomLogger(logger)
  }).onClientInitialized();
})();

Error stack trace

{
  "level":"error",
  "message":"Error initializing DevCycle: TypeError: Converting circular structure to JSON\n    --> starting at object with constructor 'DerivedLogger'\n    |     property '_readableState' -> object with constructor 'ReadableState'\n    |     property 'pipes' -> object with constructor 'Console'\n    --- property 'parent' closes the circle",
  "metadata":{},
  "timestamp":"2024-08-09T13:41:27.906Z"
}

Hi! It's me again! haha

This time I bring up something more critical, we deployed the solution to stage, then production we saw a sudden increase of memory from the pods, and then the pods started crashing due to the memory access out of bounds error.

The error started occurring more frequently, and we rolled it back.
We are using the same stack, just updated the library as you recommended.
Node: v16.20.2 (npm v8.19.4)
@devcycle/nodejs-server-sdk: ^1.30.1

RuntimeError: memory access out of bounds\n
at wasm://wasm/000c6366:wasm-function[5]:0xd06\n 
at wasm://wasm/000c6366:wasm-function[6]:0xd45\n
at wasm://wasm/000c6366:wasm-function[499]:0x2b403\n
at wasm://wasm/000c6366:wasm-function[12]:0x1308\n
at wasm://wasm/000c6366:wasm-function[15]:0x1661\n
at __lowerTypedArray (/app/dist/node_modules/@devcycle/bucketing-assembly-script/build/bucketing-lib.release.js:573:38)\n
at Object.variableForUser_PB (/app/dist/node_modules/@devcycle/bucketing-assembly-script/build/bucketing-lib.release.js:100:18)\n 
at variableForUser_PB (/app/dist/node_modules/@devcycle/nodejs-server-sdk/src/utils/userBucketingHelper.js:52:65)\n
at DevCycleClient.variable (/app/dist/node_modules/@devcycle/nodejs-server-sdk/src/client.js:159:77)\n
at DevCycleClient.variableValue (/app/dist/node_modules/@devcycle/nodejs-server-sdk/src/client.js:177:21)\n

Could someone help with this issue?

Hi! I've been implementing the @devcycle/nodejs-server-sdk in my node backend code, and I am facing some issues with initializing the SDK incorrectly. The configuration looks right, but I noticed that the SDK fails to initialize (a few times)

The application I am integrating it is using:
Node: v16.20.2 (npm v8.19.4)
@devcycle/nodejs-server-sdk: ^1.30.0

Init code snippet:

const DEVCYCLE_SERVER_SDK_KEY = process.env.DEVCYCLE_SERVER_SDK_KEY ?? '';
let devcycleClient: DevCycleClient;

export const initDevCycle = async () => {
    devcycleClient = await initializeDevCycle(DEVCYCLE_SERVER_SDK_KEY, {
        logger: logger,
        logLevel: 'debug',
        enableCloudBucketing: false,
        configPollingIntervalMS: 10 * 1000,
    }).onClientInitialized((err) => {
        logger.error(`Fail to initialize DevCycle: ${err}`);
    });
    devcycleClient.isInitialized && logger.info('Initialized DevCycle');
};

Looking at the logs using the debug mode, I can see:

DEBUG: Requesting new config for https://config-cdn.devcycle.com/config/v1/server/dvc_server_xxx.json, etag: undefined, last-modified: undefined
ERROR: Error initializing DevCycle: Error: Config data is not set. in assembly/managers/configDataManager.ts:11:9
ERROR: Fail to initialize DevCycle: undefined

What is wrong with this configuration? I see that theconfigDataManager is validating the sdk value. However, after digging my code I noticed that the SDK value is being inserted correctly. I tried to remove all extra configuration values too, with no difference in the outcome. As mentioned at the top, it worked a few times and stopped working.

Hello! I am currently working with DVC's @devcycle/devcycle-react-sdk package and am using the withDevCycleProvider HOC. The component I am passing to the HOC requires a React ref be forwarded and so, that component is wrapped in forwardRef from React. withDevCycleProvider does not return WrappedComponent wrapped in forwardRef. This is causing the ref to be lost.

const Component = forwardRef((props, ref) => { ....... });

export default withDevCycleProvider(configObject)(Component);  <-- returns a WrappedComponent with no forwarded ref

Environment
@devcycle/devcycle-react-sdk: ^1.11.5
node: 18.18.0
npm: 9.8.1

Hi,

more or less related to #468, when playing around with js-sdk for Angular, I noticed that sometimes in contrast to what is described here, the SSE connection is not dropped when the user de-focuses the current page and a new one is created when returning to the page resulting in two open connections.

On other hand, in another situation the connection was open all the time regardless of whether the page is focused or not.

Are you able to somehow reproduce this on your side? Or put differently, what would be the expected behavior?

Best regards,
Alex

JS SDK depends on window object being present, which does not exist in browser extensions built on manifest v3. NodeJS SDK on the other hand, depends on packages specific to NodeJS, which leaves no options to use in extension service workers.

From looking at the code, usages of window.localStorage, window.navigator.userAgent and window.addEventListener are the only instances where a window is needed. Hovewer, it is assumed that if window.addEventListener does not exist, this must be a react native app.

See line 44 of environmentConfigManager.ts - whilst the initial fetchConfigPromise is exposed to consumers so that they can handle any rejections accordingly, the subsequent fetch promises that are created per line 44 according to the polling interval are not exposed to consumer land and therefore if any of them fail, they can result in an unhandled rejections (line 82). This could potentially stop our node server process from being able to start (during autoscaling for instance) if there was an issue downloading dev cycle config.

Note: this would only happen if both the initial dev cycle config failed as well as subsequent polls. In other words, if the initial dev cycle config download success, consumers wont run into this issue.

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.

Looking at the code here, it looks like we are only starting a StreamingConnection on initialization. No connection is created on calling identifyUser. Is that indented?

I have recently included DevCycle in my application and experienced unexpected behavior.
My expectation is that the client should not initialize if DVC cannot be reached or an invalid client SDK key is provided.

Reproduce steps

Scenario 1

An invalid SDK key is provided to the client.

Scenario 2

The DVC server cannot be reached. I was able to reproduce this by blocking network requests to DVC servers in Chrome devtools.

Example code

try {
  const client = await initializeDevCycle('invalid-client-id', {}).onClientInitialized();
  console.log('Is client initialized: ' + client.isInitialized);
} catch (error) {
  console.log('An error occurred');
}

Expected output:

'An error occurred' // console.log

Actual output:

'Is client initialized: true' // console.log
Further more, because the client initializes successfully, when await client.identifyUser(user) is invoked, an unhandled exception occurs -- seemingly in the background? -- and my application hangs.

I've been able to temporarily workaround the issue by pairing disabling of the config cache as well as verifying the client.config.project object is undefined, but this is certainly hacky.

That code looks something like

const client = await initializeDevCycle('invalid-client-id', { disableConfigCache: true }).onClientInitialized();

// only identify the user when project is truthy
if (client.config?.project) {
  await client.identifyUser(user);
}

You might have leaked a private NPM package or forgot to publish something?

This error happened while installing the dependencies of @devcycle/[email protected]
@devcycle/bucketing-test-data is not in the npm registry, or you have no permission to fetch it.

Hey DevCycle team,

This is not affecting me in any way, but I wanted to point it out as it may result in a tricky-to-debug problem for someone else.

In initializeDevCycle an event handler is registered for the pagehide event (source). As far as I can tell this event handler is never removed when a client is closed. There is also an event handler registration for the visibilitychange event when the client is created but this handler appears to be being cleaned up properly as part of the client's close method.

Hi,

after successfully using Node.js SDK, I wanted to try integrating your library in an Angular app. It works as expected, so thanks for that.

What I realized though is that there are 3 types of requests:

• https://sdk-api.devcycle.com/ -> for retrieving flag values
• https://events.devcycle.com/v1/events -> for posting user events
• https://realtime.ably.io/ -> SSE provider connection

In the end, my motivation is to hide these calls behind my custom domain as explained here, but since I assume that this will only work for *.devcycle.com domains & because I don't need real-time updates, I wanted to know if it is possible to completely disable that feature.

If not yet possible to disable via configuration, is this something you'd expect to be implemented in the near future?

Best regards,
Alex

It would be great if I could initialize the client client (haha don't know what else to call it) with flag values that I got from the server.

FWIW, the launch darkly sdk allows you to pass in an option called "bootstrap" which is a list of all flags.

I upgraded from: @devcycle/[email protected] -> @devcycle/[email protected]

After this upgrade useIsDevCycleInitialized never returns true

To identify the breaking version I installed all releases between 1.11.11 and 1.14.3

It seems like the breaking change was introduced at @devcycle/[email protected]

If I install @devcycle/[email protected] everything is fine.

My app has one entry point structure and environment is related to the info which passed in token. Can I reinstantiate the initialization of connection with correct env key?
I'm working with @devcycle/react-client-sdk

I'm having a particular problem with a angular legacy project, in angular 1.5.x and node lts/fermium (14.20.22). I'm trying to initialize the with my credentials. In node SDK works, but in js SDK get this strange error on axios.

This occurs when I import the initialize:
import { initialize } from '@devcycle/devcycle-js-sdk'

I have a next js app using the app router. I have added the devcycle provider following these instructions. However, after changing a flag, the page never updates. It is only after waiting a bit and doing a hard refresh that the new value for the flag is available for both client and server components. The eventstream does immediately show a change but no update is triggered on the feature flags. What am I doing wrong? I have a minimum reproduction here

I used "@devcycle/devcycle-react-sdk": "^1.9.1" and started my test app, but got those "Failed to parse source map" warnings from @devcycle/devcycle-js-sdk

WARNING in ./node_modules/@devcycle/devcycle-js-sdk/src/utils.js
Module Warning (from ./node_modules/source-map-loader/dist/cjs.js):
Failed to parse source map from '/Users/test/sdk/js/src/utils.ts' file: Error: ENOENT: no such file or directory, open '/Users/test/sdk/js/src/utils.ts'

It tried to find those source files from my test project.