Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added a Bull client, and a route /feeds/info to query queue's info #2541

Merged
merged 1 commit into from Dec 10, 2021

Conversation

TueeNguyen
Copy link
Contributor

@TueeNguyen TueeNguyen commented Nov 28, 2021

Issue This PR Addresses

This fixes #2414

Type of Change

  • Bugfix: Change which fixes an issue
  • New Feature: Change which adds functionality
  • Documentation Update: Change which improves documentation
  • UI: Change which improves UI

Description

This is draft PR for issue #2414.

I added a new file queue.js that creates and exports a new Bull client with redis client connection required from posts/src/redis.js. I also added a new GET route feeds/info to return the queue's information, for now I'm trying to return the number of jobs in the queue.

I tested the route by running npm run services:start, npm start first and running http://localhost/v1/posts/feeds/info in Postman. However, I haven't got the expected response, please let me know if I'm on the right track!

The response I got was a long loading screen until Bad Gateway

Checklist

  • Quality: This PR builds and passes our npm test and works locally
  • Tests: This PR includes thorough tests or an explanation of why it does not
  • Screenshots: This PR includes screenshots or GIFs of the changes made or an explanation of why it does not (if applicable)
  • Documentation: This PR includes updated/added documentation to user exposed functionality or configuration variables are added/changed or an explanation of why it does not(if applicable)

@gitpod-io
Copy link

gitpod-io bot commented Nov 28, 2021

Copy link
Contributor

@humphd humphd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should try running this in GitPod so you don't have to set everything up locally.

Also, you have some lint errors to fix.

logger.error({ error }, "Unable to get queue's info");
next(error);
}
res.json({ jobNum: jobNum });
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Move this to after line 42, inside the try/catch. Also, you don't need to repeat jobNum:

res.json({ jobNum });

@@ -42,7 +55,7 @@ feeds.get('/:id', validateFeedsIdParam(), async (req, res, next) => {
const feed = await Feed.byId(id);
if (!feed) {
res.status(404).json({
message: `Feed not found for id ${id}`,
message: `Feed not found fore id ${id}`,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Spelling mistake. Should be for not fore.

feeds.get('/info', async (req, res, next) => {
let jobNum;
try {
jobNum = await queue.count();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested on GitPod and this route never seems to return (e.g., I get no response from the server, it just loads forever). It looks like you're doing it correctly, but there's nothing coming back.

@TueeNguyen
Copy link
Contributor Author

That's what I got for my response as well, the idea seems correct though. I'll look more into it

@humphd
Copy link
Contributor

humphd commented Nov 29, 2021

I suspect that the connection to Redis isn't right somehow (e.g., it's never returning a response).

@TueeNguyen
Copy link
Contributor Author

I'll compare it to the connection in backend. Is it possible to log the connection using logger?

@TueeNguyen
Copy link
Contributor Author

Hi @humphd, it's not returning any data because the redis clients from backend and posts have different host.

The Redis_URL in backend is redis:://127.0.0.1 while the one from satellite is redis://redis:6379

const redisUrl = process.env.REDIS_URL || 'redis://redis:6379'; // redis.js from satellite

parseUrl(process.env.REDIS_URL, process.env.REDIS_PORT) || 'redis://127.0.0.1:6379';

I tried uncommenting this line #REDIS_URL=redis://127.0.0.1 from env.development and building the containers again using docker-compose --env-file ./config/env.development up --build but the host remain the same.

How do I change the variable REDIS_URL to redis:://127.0.0.1 for satellite's redis.js file

@humphd
Copy link
Contributor

humphd commented Dec 1, 2021

Fantastic detective work! I'm really impressed that you didn't give up, and kept pushing to find the underlying problem. That's awesome.

We should change the backend to match the microservices, unless @manekenpix or @HyperTHD have a better idea?

NOTE: all the config happens via environment variables in the *.env files https://github.com/Seneca-CDOT/telescope/tree/master/config, so that's:

We also override things in the docker-compose* files in https://github.com/Seneca-CDOT/telescope/blob/master/docker. For example, I think we should probably change this to use the docker network instead of exposing:

https://github.com/Seneca-CDOT/telescope/blob/master/docker/development.yml#L72-L74

I'd have to sit with this for a while to wrap my head around it, but in general, I think the backend should be bent to work the same way as the stuff in src/api with Satellite. We're going to be getting rid of it in upcoming releases.

@TueeNguyen
Copy link
Contributor Author

Thank you! I tested it out and the queue from api successfully returned stats data.

If cleaning up the backend is on the list for the next release, it'll be probably late for my release 0.4. Also, I don't think I should touch the configuration of backend in this PR (maybe in another PR).

So how should I move forward from here, should I wait for the other devs' ideas?

@manekenpix
Copy link
Member

I'm not sure if this is a redis issue since all the other endpoints in api/posts rely on the same redis client used in the feeds/info endpoint, and they all can connect and retrieve data from redis.

@humphd
Copy link
Contributor

humphd commented Dec 1, 2021

I agree it's odd that this isn't working, since everything else is running against that same Redis instance. Is it just your dev setup?

@TueeNguyen
Copy link
Contributor Author

TueeNguyen commented Dec 2, 2021

I agree, if it works for other endpoints why not info?

It's just when I followed Josue's instructions, the promise from queue.count() got resolved once, when /info was hit, it still didn't return nothing. I thought changing the .env would solve the problem.

I'll keep trying.

@TueeNguyen
Copy link
Contributor Author

TueeNguyen commented Dec 2, 2021

Turns out, I need to provide the createClient with type client or subscriber for queues to share the same connection according to the documentation.
This is the response I've got for now, completed is also 0

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

The reason completed is 0 is because of the 2 properties below are true.

removeOnComplete: true,
removeOnFail: true,

I also added the 2 options const redis = Redis({ maxRetriesPerRequest: null, enableReadyCheck: false }); in redis.js because I ran into this problem when building the containers. The CHANGELOG from Bull also mentions this. Seems like it didn't pass the test

docker-error

Copy link
Contributor

@humphd humphd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to add a test for this as well in https://github.com/Seneca-CDOT/telescope/blob/master/src/api/posts/test/posts.test.js. We won't have real data, but hopefully it should return something.

I'm fine if you do that test here or in a follow-up PR. If you do the latter, please file the issue now.

src/api/posts/src/redis.js Outdated Show resolved Hide resolved
src/api/posts/src/routes/feeds.js Outdated Show resolved Hide resolved
@TueeNguyen
Copy link
Contributor Author

We need to add a test for this as well in https://github.com/Seneca-CDOT/telescope/blob/master/src/api/posts/test/posts.test.js. We won't have real data, but hopefully it should return something.

I'm fine if you do that test here or in a follow-up PR. If you do the latter, please file the issue now.

I'll add tests in this PR

@TueeNguyen
Copy link
Contributor Author

Hi, for now, waiting, active, delayed, jobCnt of the response updates on changes of the queue. completed, failed are always 0 as completed and failed jobs are removed from the queue.

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

I try listening for completed queue events but the event is never fired as the queue in post is not consumer or producer. I also try adding 'global:completed', the event is fired and I've got expected response but it returns error when I try to use getJobcounts() on the queue. The error is "Connection in subscriber mode, only subscriber commands may be used"

//this event is never fired
queue.on('completed', (job) => {
  console.log(`${job.id} completed`);
});
//this event is fired but get error when trying to use Bull Api on queue
queue.on('global:completed', (jobid) => {
  console.log(`${jobid} completed`);
});

I'm not sure how to get completed and active to update. I need some help on this
Helpful doc links: bull, Global Events

@humphd
Copy link
Contributor

humphd commented Dec 4, 2021

This is one reason why doing this in the parser would make the most sense, since that's where we actually manage the queue to begin with.

That said, why don't we start with the items you can get, and do other things in follow ups?

@TueeNguyen
Copy link
Contributor Author

If that's the case, I'd love to work on the parser service later on.

I'll follow up with what I can get right now. Thanks.

humphd
humphd previously approved these changes Dec 5, 2021
humphd
humphd previously approved these changes Dec 6, 2021
@TueeNguyen
Copy link
Contributor Author

I clicked on Update Branch accidentally.

@humphd
Copy link
Contributor

humphd commented Dec 6, 2021

git checkout -B issue-2414 2fd0b98b1090925ca2869cf7a3dbabb97cf770fc
git checkout master
git pull upstream master
git checkout issue-2414
git rebase master
git push origin issue-2414 -f

@TueeNguyen
Copy link
Contributor Author

After this got merged, I need to work on the front-end right?

@humphd
Copy link
Contributor

humphd commented Dec 6, 2021

Yup, you can start now if you want, just base your new branch on this branch, and rebase onto master when it lands.

humphd
humphd previously approved these changes Dec 6, 2021
@TueeNguyen
Copy link
Contributor Author

Got it!

HyperTHD
HyperTHD previously approved these changes Dec 6, 2021
Copy link
Contributor

@HyperTHD HyperTHD left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just for reference, Redis was added to Satellite so we should extract it from there. That way, we can also remove ioredis and ioredis-mock from the posts service. We can do that in another issue though. Nice job

@TueeNguyen TueeNguyen mentioned this pull request Dec 8, 2021
8 tasks
@humphd
Copy link
Contributor

humphd commented Dec 10, 2021

@TueNguyen2911 let's get this in soon, can you rebase and fix the conflict in your package.json? Ping me when it's ready so I can merge.

@@ -17,6 +17,7 @@
},
"dependencies": {
"@senecacdot/satellite": "^1.x",
"bull": "^3.20.1",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because you a dependency, you need to also update the pnpm lock file and commit that as well.

- Added a test for the new route
- Added Bull to package.json
- Added a new file queue.js to create a Bull queue
- Updated pnpm-lock.yaml
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Expose basic feed queue stats from Status service
4 participants