Lab 7.1: validate.js timeout restriction too strict?

donaldsebleung

I just did Lab 7.1 and ran the tests with node validate. I passed the first 6 test cases, and then the tests hung for 1.5 seconds (since one of the backend services is down), and then I get a failed assertion "GET http://localhost:3000/1 failed to respond". So I dug into validate.js to figure out what was going on, changed line 27 (in the get function) to timeout at 4 seconds instead of 1.5, and re-ran the tests, which then passed successfully.

Since the lab exercise did not mention that our "front of the back-end" service should forcibly cut the connection(s) to back-end services after a given time limit, I suppose that this is unintentional? In case it matters, I'm doing the lab exercises on Ubuntu 20.04 LTS.

ariel15584

Having the same issue here, got library has a different timeout than the test. I had to add a timeout to GOT to make it work:

const boat = await got(${BOAT_SERVICE}/${id}, {
timeout:500,
retry: 0
}).json();

davidmarkclements

this is a fair point, the lab has been clarified with an extra bullet point:

Be sure that if an upstream service is not available, that the service responds within 1250ms.

(this allows an additional 250ms for processing)

luxfero

the problem is that with got module you need to also set retry to 0 in order to validate the exercice

dominik.urban

Could you, at least, add in the lesson section the timeout and retry options for "got"? It is hard to grasp if you don't know these details.
And if you know and add the timeout option, you have to know and add the retry option as well. That is too though, if you have no idea where the issue is.

Would be great!
Cheers!

davidmarkclements

@dominik.urban the approach of the material is heavily focused on concepts & understanding - it's about fundamentals. There is no requirement to use got on the exam, there are many many client http libraries, all with different ways to handle this. The fact you found it hard to grasp and yet grasped it any way means that you've traversed the learning curve for this particular challenging scenario - which is great!

dominik.urban

thanks for your reply. imo you could at a info to consider eventually timeouts, as a conceptual consideration 😉👍

gregsheppard

I like @davidmarkclements point about the learning curve. I had to come to the forum before realizing that I should have looked into retries as well as timeouts when using got but having puzzled over it for a while beforehand I now have no trouble recalling that tidbit. You don't want to overdo it but the learning is in the struggle.

davidmarkclements

the content that makes it into the material is all about trade-offs - the emphasis is on filling knowledge gaps through fundamentals and signposting. The timeout stuff is a signposting thing, and I'm very much of that school of thought @greggsheppard aptly summarised with "the learning is in the struggle".

gregsheppard

Thanks @davidmarkclements. I should add that I went through an entire pass of LFW211 before realizing that the forum existed so it might be nice to display that more prominently in the courses but yes, when you bang your head against something, it leaves an imprint.

mstepien

Hi @gregsheppard,

We provide information about the course forum in the first chapter, page "Course Support".

Thank you,
Magda
The Linux Foundation Training Team

gregsheppard

Yes, I did figure this out when I went back for a second pass through the course. The first time I was very eager to get started on the material and sped through the onboarding pages without noticing.