fjtirado commented on issue #3573: URL: https://github.com/apache/incubator-kie-kogito-runtimes/issues/3573#issuecomment-2236250719
> There is a delicate detail here - that the context variable used in the jq expression must exist at the state where this invocation happens. it is very easy to override context variables by other states and loose them. So lets say the usage of this openapi action is several state down the workflow, there is a huge chance .clustername would just be overwritten. > > How can we make sure this configkey selection strategy is easy to grasp, harder to ruin, easy to debug if needed ? can we analyze the states that overwrite the whole data context and warn? maybe at build time? but then again the config key is runtime mutable. Really good point!!! My first idea was that we should evaluate the expression at the moment the OpenAPI invocation is done. And indeed the possibility that the expression returns nothing. After thinking about the alternatives, one possibility is evaluating also at the beginning. Therefore the algoritm will be, if the property quarkus......runtimeConfigKey is set, then it is evaluated against the input model when the workflow is started, and the calculated value, if existings, is stored as part of the process instance internal info (that is keep in DB). Then, when the openapi call happened, it is evaluated again. If there is a value, thats the value to be used in the call. If there is not value, then the value calculated when the workflows was started, if existing, will be used. If there is not value, then the build time config key will be used. If not matching property is found, then the URI in the spec will be used (and the call will very likely faild because wrong uri, we can add message to review the properties, naming them) -- 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]
