Christine-Jose opened a new issue, #7240:
URL: https://github.com/apache/incubator-kie/issues/7240
### Describe the bug
Three internal parameters were added to support WIH exception handling
configuration:
ErrorHandlerProcessId
ErrorHandlingStrategy
ErrorHandlingRetries
When these parameters are used as User Task input mappings, they are
currently included in the generated JSON schema for the task. This is
undesirable because they are internal/infrastructure-level parameters and
should not be surfaced as part of the task's data contract.
Problem
The JSON schema generation for User Tasks picks up all input parameters,
including the error-handling ones introduced by
ProcessWorkItemHandlerExceptionHandler. For example, a User Task with a single
username input mapping and error-handling configuration currently produces a
schema like:
{
"$schema": "https://json-schema.org/draft/2019-09/schema",
"type": "object",
"properties": {
"ErrorHandlerProcessId": {
"type": "string",
"input": true
},
"ErrorHandlingRetries": {
"type": "integer",
"input": true
},
"ErrorHandlingStrategy": {
"type": "string",
"input": true
},
"username": {
"type": "string",
"input": true,
"output": true
}
}
}
The expected schema should only contain username, with no trace of the
internal error-handling parameters.
Proposed Solution
Exclude ErrorHandlerProcessId, ErrorHandlingStrategy, and
ErrorHandlingRetries from the User Task JSON schema generation, treating them
as reserved/internal parameters similarly to how other engine-level parameters
are handled.
The constants are already defined in ProcessWorkItemHandlerExceptionHandler
and can be reused as a filter list during schema generation.
Acceptance Criteria
ErrorHandlerProcessId, ErrorHandlingStrategy, and ErrorHandlingRetries do
not appear in the generated JSON schema for User Tasks.
The parameters continue to function correctly at runtime for exception
handling purposes.
Existing behaviour for all other User Task input parameters is unchanged.
### Expected behavior
_No response_
### Actual behavior
_No response_
### How to Reproduce?
_No response_
### Output of `uname -a` or `ver`
_No response_
### Output of `java -version`
_No response_
### GraalVM version (if different from Java)
_No response_
### Kogito version or git rev (or at least Quarkus version if you are using
Kogito via Quarkus platform BOM)
_No response_
### Build tool (ie. output of `mvnw --version` or `gradlew --version`)
_No response_
### Additional information
_No response_
--
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]