Ignore ENETUNREACH no route to host errors and continue script

[onny]

Hey,
I would like to continue the execution of the script in case of an ENETUNREACH error. This occours when the requested target domain is not reachable.
In my example script, there is the possibility that a certain site sometimes is available at site1.example.org or site2.example.org. So I duplicated my script to target both endpoints. If one fail because the site is not reachable, it should continue execution and try to request the second site.
Best regards
Jonas

[pmarkert]

Hi Jonas,

Apologies for the delayed response. I was out of the country working on a mission trip. This is definitely not very well documented and I have not done to maintain hyperpotamus in the recent past, but you can already achieve this with something similar to the following:

- request:
       url: https://site1.example.org/
     on_failure:
       - if:
           equals: [ <% error.jse_cause.errno %>, -3008 ]
         then:
           print: Continue
         else:
           print: Error

any action can have an on_failure or on_success element/tree that is evaluated correspondingly. In this case, during the on_failure, there will be an error element present in the context that can be interrogated. This error is whatever was thrown from the parent action. Understanding what properties are available on the error object can best be seen with the hyperpotamus debugger hdb and stepping into some of the breakpoints, but this is certainly not an ideal discovery experience. Feel free to follow up with any questions. I'm also willing to schedule a private session if you want some Q/A time. It's nice to see that someone is using and finding some value with hyperpotamus. :)

[onny]

Thank you for the response! Hyperpotamus is a really useful project. I've packaged it for NixOS and using it in some scripts.
I tried the on_failure mechanism but didn't get it work yet. This is my script:

defaults: 
  response: []

steps:

- request:
    url: http://cp.example.org/login
    on_failure:
      goto: next_gateway
  response:
    - jquery: "form[name='login'] input[name='username']"
      capture:
        macaddress: [ "@value" ]
- request:
    url: http://cp.example.org/login
    method: POST
    form:
      username: <% macaddress[0] %>
      password: test123

- name: next_gateway
  request:
    url: http://cp2.example.org/login
  response:
    - jquery: "form[name='login'] input[name='username']"
      capture:
        macaddress: [ "@value" ]
- request:
    url: http://cp2.example.org/login
    method: POST
    form:
      username: <% macaddress[0] %>
      password: test123

In some cases gateway cp.example.org isn't available but cp2.example.org might be. So instead on failing on gateway 1 it should continue and try gateway 2.

(node:30885) NOTE: We are formalizing our plans to enter AWS SDK for JavaScript (v2) into maintenance mode in 2023.

Please migrate your code to use AWS SDK for JavaScript (v3).
For more information, check the migration guide at https://a.co/7PzMCcy
(Use `node --trace-warnings ...` to show where the warning was created)
[2023-04-03T12:04:45+02:00] [action.request] [INFO] - About to send request GET http://cp.example.org/login
[2023-04-03T12:04:45+02:00] [hyperpotamus.cli] [INFO] - Error details:
request:
  headers:
    user-agent: 'Hyperpotamus/0.39.0 (+http://github.com/pmarkert/hyperpotamus)'
  url: 'http://cp.example.org/login'
  on_failure:
    goto: next_gateway
  simple: true
  resolveWithFullResponse: true
  timing:
    started: 2023-04-03T10:04:45.363Z
response: {}
action: &ref_0
  request:
    url: 'http://cp.example.org/login'
    on_failure:
      goto: next_gateway
  response:
    - jquery: 'form[name=''login''] input[name=''username'']'
      capture:
        macaddress:
          - '@value'
      path: $.steps.0.response.0
  path: $.steps.0
path: $.steps.0
session: {}
step: *ref_0

[2023-04-03T12:04:45+02:00] [hyperpotamus.cli] [ERROR] - Error occurred while processing script:
name: ResponseActionError
message: 'Error processing post-response actions for request: connect ENETUNREACH 10.172.0.1:80'
path: $.steps.0
help_link: 'https://github.com/pmarkert/hyperpotamus/wiki/errors#ResponseActionError'

[pmarkert]

The on_failure and on_success elements are universal properties that are available for any action that is being executed, so they need to be specified at the same level as the action's name/type (which is request in your case). If you out-dent the on_failure sub-tree one level (so it lines up with the request property, then I believe it should work. Universal properties like these control-flow elements should be at the top-level of the action as they can be applied to any action. Similarly if you specifically have a name property to be able to specify an action as a target for a goto or call action, that is also an action-level property.

Note: Any properties/elements that are specific to the type of action being performed are normally nested at a level underneath the action type, but request is an exception whereby the response element is not nested. if is another exception where the then and else sub-trees are not nested. I typically order the on_success and on_error elements after all other top-level action properties but it is not required.