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
Can somone have a look into this and confirm if they too are facing the same issue
@Roney_Dsilva Are you having issues with this version or š¦¬ Bull Queues for Node Version 2 ?
Hi @tbvgl, Am having issues with this version, will check with your version as well.
@tbvgl, Your version works fine. Its not affected by the upgrade.
1 Like
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?
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
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
Which version of the bull package do you currently have installed? @Roney_Dsilva
@tbvgl Its 4.10.4
Please run npm i ioredis and see if that fixes your issue.
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.
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?
@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
}
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
@tbvgl global.redisClient.options.host returns undefined.
1 Like
@umadmin How are you hosting redis? Docker ?
I just pushed a hotfix to V1 and V2.
1 Like
I was experimenting with hosted redis in digitalocean, but reverted back to docker (or at least attempted)
I had only changed the config to DO for one of my environments and this issue has persisted across all three (my local, a web dev where the DO redis settings were, and production where redis was in docker)
@tbvgl, I reverified the behavior, this issue occurs only when I change from Redis 3 to Redis 4, ie after applying the Wapply 5.8 modules and base npm package, i came to a earlier commit and verified this
console.log(global.redisClient.options.host) returns correctly on the older commit
console.log(global.redisClient.options.socket.host) returns correctly on the newer commit