Boss machine only 1 error left to fix!

So I have only one error left to fix:

60 passing (2s)
1 failing

  1. BONUS: /api/minions/:minionId/work routes
    DELETE /api/minions/:minionId/work/:workId
    deletes the correct work by id:
    TypeError: afterDeleteWorkArray.find is not a function
    at C:\Asus WebStorage\\project-4-boss-machine-start\project-4-boss-machine-start\test\test.js:800:58
    at runMicrotasks ()
    at processTicksAndRejections (internal/process/task_queues.js:97:5)

This is my delete request for the work route:

workRouter.delete("/:minionId/work/:workId", (req, res) => {

const workId = req.params.workId;

const deleteWork = deleteFromDatabasebyId(“work”, workId);

if (!deleteWork || isNaN(workId)) {


} else {




The weird thing is that it actually works when I try it on the page but still gives this weird error. Any ideas?

Hey Manu!

I didn’t run into this particular message when working on the bonus features, Did you previously validate that the workId was valid? I used the router.param() feature to validate and retrieve the query parameter before it ever reached my delete code, so maybe it had already rejected something that would have raised an error.

That method shouldn’t be required though. Maybe you could confirm that workId is valid with getFromDatabaseById. Even that may not be necessary.

One more observation is that my code returns an error 400 instead of a 404

Hopefully something in here gets you in the right direction. Looks like you’re really close to wrapping this one up.

1 Like

Thanks Scott! I’m thinking it could be some bug with the tests but I’ll check it out again with a fresh head to see if I can figure it out.

Unless we somehow have a different version of the tests, then whatever bug might be there can be avoided with a passing implementation. The bug might be just how it reports it rather than what it looks for.


Since I do the validation of workId before ever reaching this part of the code, bad ones have already been rejected.

You could add some console logging here to help troubleshoot. You’ll have to hunt for where it shows during the tests, but if you make the messages stand out then it shouldn’t be a problem. You may find that your conditional to check if the delete failed always appears to indicate it failed.

Another hint

req.params.workId is going to be a string

1 Like

You’re amazing Scott, you always go the extra mile to help. Btw I hadn’t even used router.param(), i had totally forgotten about it. That could have made everything so much easier and cleaner, thanks for reminding me. I actually implemented router.params() on my delete routes with the checks being made for the ID being valid and the ID being a number but it made no difference. Gonna keep looking, my OCD can’t let me go forward with that one error left there :stuck_out_tongue:

In order to fully implement these routes, the database helper functions may not provide all the functionality that you need, and you may need to use router parameters or other methods to attach the minionId properties correctly and handle the edge cases property.

Regarding this notice here, I actually ended up using the same helper functions for the work routes. What was it exactly that you needed to handle differently in this case? Maybe that’s where the issue is coming from.

I just noticed one more difference in your code and mine. Your call to deleteFromDatabasebyId. How did you bring that function in? I used const db = require('./db.js'); so all those functions were accessible from db.

If you brought in all the functions individually, then that won’t apply to you.

For what it’s worth, I copied your code into mine, added the db. in front of the database call, and all the tests pass for mine. So there may be something else going on.

Yeah I brought them in individually, just copied the import from the original api route file I think.

For what it’s worth, I copied your code into mine, added the db. in front of the database call, and all the tests pass for mine. So there may be something else going on.

That’s really strange then. Gonna keep looking everywhere else then, thanks for all your effort to help Scott.

I changed how I handled GET /api/minions/:minionId/work to get an array of all work for the specified minon. route.

After I used db.getAllFromDatabase('work'), I did an extra filter on the results so only the ones that apply to the specified minion were returned. But you didn’t mention having trouble with that test.

1 Like

I think I know where the issue is coming. In the PUT request on the work route the test asks me to send a 400 status if the workId and MinionId aren’t the same , and I do that correctly and pass the test but then I realized that when i try to update a work item it doesn’t work because it’s giving me a 400 error because the workId and MinionId aren’t the same. So what’s up with that? any idea?

here’s the code sorry:

workRouter.put("/:minionId/work/:workId", (req, res) => {

const workInstance = req.body;

const workId = req.params.workId;

const minionId = req.params.minionId;

const workIdCheck = getFromDatabaseById(“work”, workId);

if (isNaN(workId) || !workIdCheck) {


} else if (workId !== minionId) {


} else {

const updateWork = updateInstanceInDatabase("work", workInstance);




My interpretation of the returns a 400 if a work ID with the wrong :minionId is requested test for PUT meant that if the URL had a minionId that didn’t match the minionId contained in the update (attached to the body), then to give an error 400. This strategy ensures that someone doesn’t use a valid minionId in the URL but then try to update the minionId in the PUT request. The workId and the minionId don’t need to match each other, but they might just because of the low number of records we’re dealing with.

This was the issue all along, my initial GET request was not working as it should. Fixed it and everything works. Thanks Scott , you’re a lifesaver. Always considering every little detail that could be the issue, you’re amazing brother!

1 Like