🙋‍♀️ Trying but failing to use the pub/sub Queue in monday code

monday Apps & Developers
, , ,
1

I’m using this code to send a message to the queue, based on the documentation here:

import { Queue } from '@mondaycom/apps-sdk';
...
const sendToQueue = async (payload): Promise<String> => {
	console.log('Send this to the queue', payload);
	const queue = new Queue();
	const messageContent = JSON.stringify(payload);
	return queue.publishMessage(messageContent);
};

It’s throwing the following error (when run locally through ngrok):

file:///path/to/my-project/node_modules/@mondaycom/apps-sdk/dist/esm/utils/env.js:9
        throw new Error('En environment variable name "MNDY_SERVER_ADDRESS" is required, the value should be int the following format "(protocol)://{server_name}:{port}" e.g.: "http://localhost:8080".');
              ^

Error: En environment variable name "MNDY_SERVER_ADDRESS" is required, the value should be int the following format "(protocol)://{server_name}:{port}" e.g.: "http://localhost:8080".
    at localServerAddress (file:///path/to/my-project/node_modules/@mondaycom/apps-sdk/dist/esm/utils/env.js:9:15)
    at QueueDev.<anonymous> (file:///path/to/my-project/node_modules/@mondaycom/apps-sdk/dist/esm/queue/queue.dev.js:57:33)
    at step (file:///path/to/my-project/node_modules/@mondaycom/apps-sdk/dist/esm/queue/queue.dev.js:32:23)
    at Object.next (file:///path/to/my-project/node_modules/@mondaycom/apps-sdk/dist/esm/queue/queue.dev.js:13:53)
    at file:///path/to/my-project/node_modules/@mondaycom/apps-sdk/dist/esm/queue/queue.dev.js:7:71
    at new Promise (<anonymous>)
    at __awaiter (file:///path/to/my-project/node_modules/@mondaycom/apps-sdk/dist/esm/queue/queue.dev.js:3:12)
    at QueueDev.publishMessage (file:///path/to/my-project/node_modules/@mondaycom/apps-sdk/dist/esm/queue/queue.dev.js:53:16)
    at sendToQueue (/path/to/my-project/src/routes/integrations/actions/copy-sharepoint-folder/+server.ts:103:16)
    at POST (/path/to/my-project/src/routes/integrations/actions/copy-sharepoint-folder/+server.ts:56:7)

Help!

  • What’s going on with the error above?
  • Where does MNDY_SERVER_ADDRESS come from?
  • I’ve not seen MNDY_SERVER_ADDRESS anywhere in the docs

Screenshot 2024-05-30 at 13.13.57
Screenshot 2024-05-30 at 13.13.572052×1344 153 KB

2

Oh, it looks like there’s documentation missing.

The dev queue simply sends a fetch to /mndy-queue on your dev server, but it looks for MNDY_SERVER_ADDRESS env variable to achieve this.

See:

I imagine it works a little differently on production :slight_smile:

To get this working on Sveltekit, I had to adjust my package.json:

{
  ...
  "scripts": {
    "dev": "MNDY_SERVER_ADDRESS=http://localhost:5173 vite dev",
    ...
  }
  ...
}

…because Sveltekit doesn’t load env vars from .env in quite the same manner as nodejs, so this is a convenient way around that problem.

@Matias.Monday perhaps details of MNDY_SERVER_ADDRESS could be added to the docs for using monday-code queue on a local development system?

1 Like
3

Hi David,

We’ve succesfully implemented the monday code queue system both locally and in production. In my local env file I have my local address set as MNDY_SERVER_ADDRESS:

MNDY_SERVER_ADDRESS=http://localhost:8080

On monday Code itself I can’t recall setting the env var but my colleague (who’s on holiday) has set it up initially so can’t be certain. However I did release a new version at a later time and didn’t have to change any env variable to update the queue to use the new url. And it’s not using the live url to process new events so monday code, somewhere handles it themselves.

However we ran into an issue a few weeks ago where we had a bug in our code which resulted in the same event being retried forever (pub sub kept trying by calling our version url of the live version at that time).

After fixing the issue and deploying/publishing a new version, the event kept being send to the old version url. New events were being send to the latest version url though. Support has fixed the issue but we haven’t gotten an explanation as to how, so it’s currently uncertain if it was a fix for this single “stuck” event or a permanent fix for future deploys as well.

So somewhere, monday Code seems to take care of the MNDY_SERVER_ADDRESS env variable.

2 Likes