Welcome to the Linux Foundation Forum!

Lab 7.1: validate.js timeout restriction too strict?

Options
donaldsebleung
donaldsebleung Posts: 21
in LFW212 Class Forum

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

  • davidmarkclements
    davidmarkclements Posts: 270
    Options

    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
    luxfero Posts: 4
    Options

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

  • dominik.urban
    dominik.urban Posts: 9
    Options

    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
    davidmarkclements Posts: 270
    Options

    @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 2021
    Options

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

  • gregsheppard
    gregsheppard Posts: 31
    Options

    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
    davidmarkclements Posts: 270
    Options

    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
    gregsheppard Posts: 31
    Options

    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: 422
    Options

    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
    gregsheppard Posts: 31
    Options

    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