🐛 Bug Report: @novu/frameworks throws no reasonable error when having invalid configuration

[paulwer]

📜 Description

We had an error, which was releated, to an invalid configuration of our env variables: NOVU_API_URL and NOVU_SECRET_KEY.
We had used the @novu/node lib before and therefore had env in place which met the naming from this lib. (NOVU_BACKEND_URL/NOVU_API_KEY)

This resulted in a misconfiguration (our fault, we could have been reading better :) ) with a strange/wrong debugging experience.
We had to take a deep dive why the following error was present and we were not able to pin down the exact origin for a few hours.

👟 Reproduction steps

1. Deploy self-hosted version
2. Deploy bridge server without proper env configuration

👍 Expected behavior

The system tried to reach the cloud url of novu instead of the self-hosted on, which is correct, but the error should represent, that the endpoint could not be reached with this configuration. like a 401 error or similar. The errors in the console of @novu/framework should also be more detailed.

Other suggestions:

• we would also suggest to use a similar naming across libs for the same thing :)
• manualy configurable keys, without need to just use the env vars.

👎 Actual Behavior with Screenshots

The error present at the ui was:
Workflow with id: order-recieved has an invalid state. Step with id: in-app has invalid result. Please provide the correct step result.

The console just shows, that the step could not be hydrated.

The ui shows this weird error. We think this is due to the fact, that the step before could not be handled because of the misconfiguration.

Novu version

Self Hosted

npm version

k.A.

node version

20

📃 Provide any additional context for the Bug.

[email protected]
@novu/[email protected] also tested on @novu/[email protected]

👀 Have you spent some time to check if this bug has been raised before?

• I checked and didn't find a similar issue

🏢 Have you read the Contributing Guidelines?

• I have read the Contributing Guidelines

Are you willing to submit PR?

None

Our workflow

workflow(
        'order-recieved',
        async ({ step, payload, subscriber }) => {
            await step.inApp('in-app', async () => {
                return {
                    subject: tolgee.t('inApp.orderRecieved.subject', {
                        internal_number: payload.order?.internal_number,
                        language: subscriber?.locale,
                    }),
                    body: tolgee.t('inApp.orderRecieved.body', {
                        internal_number: payload.order?.internal_number,
                        language: subscriber?.locale,
                    }),
                }
            });

            await step.push('send-push', async () => {
                return {
                    subject: tolgee.t('push.orderRecieved.subject', {
                        internal_number: payload.order?.internal_number,
                        language: subscriber?.locale,
                    }),
                    body: tolgee.t('push.orderRecieved.body', {
                        internal_number: payload.order?.internal_number,
                        language: subscriber?.locale,
                    }),
                }
            });

            await step.email('send-email', async () => {
                // TODO: support other order types
                if (payload.order.type !== 'SHOP_PURCHASE_ORDER')
                    throw new Error(`processing of incorrect order type could not be performed. ${payload.order.type}`)

                // the eshop should only support those 3 languages
                const language = ['de', 'en', 'fr'].includes(subscriber?.locale || '') ? subscriber?.locale : 'en';
                await ConfigUtil.init();
                const subject = '...';
                const body = '...';
                return {
                    subject: subject,
                    body: body,
                };
            });
        })

[linear]

NV-4537 🐛 Bug Report: @novu/frameworks throws no reasonable error when having invalid configuration

[abkorim1998]

you need to enable Preferences Feature Flag:

i did enabeld by steps

1. add this IS_WORKFLOW_PREFERENCES_ENABLED: 'true' in docker-compose.yml file

worker:
  image: 'ghcr.io/novuhq/novu/worker:latest'
  depends_on:
    mongodb:
      condition: service_healthy
    redis:
      condition: service_healthy
  container_name: worker
  restart: unless-stopped
  logging:
    driver: 'json-file'
    options:
      max-size: '50m'
      max-file: '5'
  environment:
    IS_WORKFLOW_PREFERENCES_ENABLED: 'true'
    NODE_ENV: ${NODE_ENV}
    MONGO_URL: ${MONGO_URL}
    MONGO_MAX_POOL_SIZE: ${MONGO_MAX_POOL_SIZE}
    REDIS_HOST: ${REDIS_HOST}
    REDIS_PORT: ${REDIS_PORT}
    REDIS_PASSWORD: ${REDIS_PASSWORD}
    REDIS_DB_INDEX: 2
    REDIS_CACHE_SERVICE_HOST: ${REDIS_CACHE_SERVICE_HOST}
    REDIS_CACHE_SERVICE_PORT: ${REDIS_CACHE_SERVICE_PORT}
    S3_LOCAL_STACK: ${S3_LOCAL_STACK}
    S3_BUCKET_NAME: ${S3_BUCKET_NAME}
    S3_REGION: ${S3_REGION}
    AWS_ACCESS_KEY_ID: ${AWS_ACCESS_KEY_ID}
    AWS_SECRET_ACCESS_KEY: ${AWS_SECRET_ACCESS_KEY}
    STORE_ENCRYPTION_KEY: ${STORE_ENCRYPTION_KEY}
    SENTRY_DSN: ${SENTRY_DSN}
    NEW_RELIC_APP_NAME: ${NEW_RELIC_APP_NAME}
    NEW_RELIC_LICENSE_KEY: ${NEW_RELIC_LICENSE_KEY}
    BROADCAST_QUEUE_CHUNK_SIZE: ${BROADCAST_QUEUE_CHUNK_SIZE}
    MULTICAST_QUEUE_CHUNK_SIZE: ${MULTICAST_QUEUE_CHUNK_SIZE}

2. docker-compose up -d

[paulwer]

we already did but thought this had nothing to do with each other. good input though. neverthelesse, the error is still missleading and should be looked on.