Progress on release 0.4

Last week, I managed to figure out how the feed-queue in the backend works and wrote some code to query the queue's status.
The issue: https://github.com/Seneca-CDOT/telescope/issues/2414
The PR: https://github.com/Seneca-CDOT/telescope/pull/2541

Trying to debug:

I suspected the redis connection might not be entirely the same so I wanted to put a breakpoint and stop the code to inspect. The problem was that the app runs in docker containers so it took couple of steps to set up the debugger. I did not succeed in doing so, though, I learnt more about docker configurations, it'll probably come in handy in the near future. I ended up using console.log.

Changing the approach:

After some discussions with the other devs, I decided that the redis connection is the correct because it works for other endpoints. I took some time reading Bull's documentation again, it turned out that I did not provide the createClient a client type.

When type is client or subscriber you can return the same connection for multiple queues, which can reduce the number of connections you open to the redis server

Therefore, I added a function to provide the connection a client type

const queue = new Bull('feed-queue', {
  createClient: (type) => {
    switch (type) {
      case 'client':
        return client;
      case 'subscriber':
        return subscriber;
      default:
        return redis;
    }
  },
});

Which also returns

{"queueInfo":{"waiting":785,"active":0,"completed":0,"failed":2,"delayed":0,"paused":0,"jobCnt":785}}

Since the queue in the backend removes any completed or failed job from the queue, active and completed were always 0. I tried listening the completed and failed events but since queue in posts is it a producer/worker, it's not possible to do so which is mentioned here. Telescope also has parser service to handle this more efficiently but it hasn't been used.

Wrapping up

I agreed with David to use what I had for now for the front-end, then I wrote some tests for the need endpoint. All in all, this doesn't seem like a lot of work but it took me some time to understand Bull queue and I think this knowledge will be useful if I work on parser service next semester.