🦬 Bull Queues for Node

Wappler Extensions
#59

nvm I got it to work by using the app directly:

const app = new App({ method: `POST`, body: jobData, session: {}, cookies: {}, signedCookies: {}, query: {}, headers: {} });
            const actionFile = await fs.readJSON(`app/api/${action}.json`);

            await app.define(actionFile, true);

This will allow us to support get requests, sessions etc as well in a later version and we don’t need to worry about localhost anymore :smiley:

1 Like
#60

To change from lib to action, just create the action and set params instead of GET or POST?

#61

Yeah, but libs work a little different under the hood and I still don’t see a single good reason to support them for bull jobs.

1 Like
#62

It appears that the newly updated Redis modules in 5.8 have broken this extension functionality.
Queues are not getting created, nor any errors returned

#63

Can somone have a look into this and confirm if they too are facing the same issue

#64

@Roney_Dsilva Are you having issues with this version or 🦬 Bull Queues for Node Version 2 ?

#65

Hi @tbvgl, Am having issues with this version, will check with your version as well.

#66

@tbvgl, Your version works fine. Its not affected by the upgrade.

1 Like
#67

Okay. It might be an outdated ioredis or bull dependency in V1. I don’t have the capacity to maintain V1 anymore, though, and I’m not sure if Ken does. Maybe upgrade to V2 if you don’t depend on library actions for bull jobs?

#68

:sweat_smile: Thats the problem, I have dependencies on Library actions for bull jobs.

Mind if I ask why that’s been removed in V2, wouldn’t it be better to keep that option also available to users who don’t want to expose those backend functionality api’s

#69

They were removed in V2 because they caused frequent issues in V1 and were hard to maintain. They might work better with the new job processor in V2, but I didn’t find a good reason to support them for job executions yet.

As a workaround, include the library actions inside a standard API workflow and execute that API workflow via a job.

1 Like
#70

Which version of the bull package do you currently have installed? @Roney_Dsilva

#71

@tbvgl Its 4.10.4

#72

Please run npm i ioredis and see if that fixes your issue.

#73

Hi @tbvgl, I tried that, didn’t help.
However setting a static hostname somehow fixed it for me,
host: process.env.REDIS_HOST || global.redisClient ? global.redisClient.options.host : {}
to host: 'redis'

Had done the same in your version aswell when testing it, so basically the problem exists for me in your version aswell.

This might be for me only, some internal hostname resolution issue probably.

#74

Cross posting from a different thread. Since upgrading to 5.8 yesterday, I’m constantly getting this error [ioredis] Unhandled error event: Error: connect ECONNREFUSED 127.0.0.1:6379
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1494:16)
Is this related?

#75

@tbvgl, Found the issue.

the hostname normally found in global.redisClient.options.host
is now found at global.redisClient.options.socket.host

The below block is returned in global.redisClient.options

socket: {
    host: 'redis',
    port: 6379,
    connectTimeout: 5000,
    keepAlive: 5000,
    noDelay: true
  }
#76

Thanks, are you hosting the Redis db via Wappler docker service or somewhere else?

I just checked, and global.redisClient.options.host still has the same hostnames as before as well.

Can you check what global.redisClient.options.host outputs for you or if it is empty?
You can add a console.log to bull_queues.js directly under exports.create_queue = async function(options):

console.log(global.redisClient.options.host)

and check what that outputs.

I guess it is only under socket if you are using sockets or host Redis via Wappler but need to confirm. If global.redisClient.options.host is empty for you then I can add the socket as a fallback.

1 Like
#77

@tbvgl global.redisClient.options.host returns undefined.

1 Like
#78

@umadmin How are you hosting redis? Docker ?