Welcome to the Linux Foundation Forum!

Lab 7.1: validate.js timeout restriction too strict?

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.

Comments

  • 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)

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

  • 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! :)

  • @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
    dominik.urban Posts: 9
    edited October 27

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

  • 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.

  • 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".

  • 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
    mstepien Posts: 216

    Hi @gregsheppard,

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

    Thank you,
    Magda
    The Linux Foundation Training Team

  • 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.

Categories

Upcoming Training