SALTO-6715: Return early from type fetcher on depends on context

[shir-reifenberg]

This fixes a bug in dependsOn, when the previous request returned no results

---

Additional context for reviewer
If type A dependsOn type B, and the request of type B returned no results (either cause it's failed or empty in the service), we would have still make the request to type A, although there is not point as the will be missing context.

I added another check to catch this scenario in advance, the alternative (as today) is throwing an error when calculating the request args (in contextPossibleArgs)

This was causing noisy logs of "failure" though it's not really a failure

Didn't add tests as the entire file doesn't have any :(

---

Release Notes:
None

---

User Notifications:
None

[Nurdok]

Can you share the failure logs you found and the scenario?

I'm a little worried that this can cause issues where there's some legitimate reason the context is empty (perhaps it's used in a condition, and it can be empty sometimes), or even misconfiguration by an adapter developer where they specified dependsOn but don't always use it - I think a confusing error log might be better than not sending a request where we need to. In any case, an error seems appropriate if the resource depends on a context arg that isn't found - aren't you just hiding an actual error here?

[shir-reifenberg]

Can you share the failure logs you found and the scenario?

I'm a little worried that this can cause issues where there's some legitimate reason the context is empty (perhaps it's used in a condition, and it can be empty sometimes), or even misconfiguration by an adapter developer where they specified dependsOn but don't always use it - I think a confusing error log might be better than not sending a request where we need to. In any case, an error seems appropriate if the resource depends on a context arg that isn't found - aren't you just hiding an actual error here?

The error log -
error adapter-components/fetch/element/element adapterName="jamf" typeName="mac_application" unexpectedly failed to fetch type jamf:mac_application: value /JSSResource/macapplications/id/{id} still contains unresolved args: id

This can happen in two cases -

1. when the "parent" request (in this case /JSSResource/macapplications returned no result)
2. when the "parent request failed - if this is the case, we'll also have a similar log for unexpectedly failed to fetch type jamf:parent_type, so for your question, we're not hiding the real error.

re legitimate empty context, seems like the code is is throwing on unresolved arg anyway, I agree in case of condition it might be overlooked, but I think there are other ways to implement it?

The motivation for this change is to allow us to monitor types failure, and this log is currently "noisy"