oEscal commented on PR #3939:
URL:
https://github.com/apache/incubator-kie-kogito-runtimes/pull/3939#issuecomment-4083745807
@fjtirado After studying my implementation with more attention, I now
understand what I did better (this was 5 months ago).
The original intention of issue #3938 was to have a way of giving Knative
custom functions the visibility over the returned status code (and message), as
well as the returned headers. As described in the issue, this could be done
using the params `failOnStatusError`, `returnStatusCode`, and `returnHeaders`
when defining the function in the workflow, as follows:
```
"functions": [
{
"name": "greet",
"type": "custom",
"operation":
"knative:services.v1.serving.knative.dev/custom-function-knative-service?failOnStatusError=false&returnStatusCode=true&returnHeaders=false"
}
]
```
However, after implementing PR #3937, where we discussed using the variable
`$WORKFLOW` to give access to the status code, status message, and response
headers, I thought of continuing that implementation here. Therefore, this data
could be accessed the same way as with the REST custom function: through the
variable `$WORKFLOW`. Moreover, with the implementation in this PR, we can also
define if the function should fail on status code with the key
`failOnStatusCode` defined on the function metadata, as we can already do with
the REST custom function. That is the reason for me including this line in the
implementation:
https://github.com/apache/incubator-kie-kogito-runtimes/pull/3939#discussion_r2945834434.
As for this part of the implementation
(https://github.com/apache/incubator-kie-kogito-runtimes/pull/3939#discussion_r2945845517),
I already tried to clarify the implementation and make it more linear.
However, this implementation is not completely related to the issue at hand. As
I explained in a [comment
above](https://github.com/apache/incubator-kie-kogito-runtimes/pull/3939#issuecomment-3462703571),
it allows to automatically get the `HEADER_*` or `QUERY_*` from the body
response of the previous function and inject them as headers or queries in the
request of the current function. Since this implementation is not completely
related to this issue, do you prefer I create another issue that explains it
and implement it in a separate PR?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
