Update decisionservice result evaluation logic to account for implicit conversion#746
Open
AthiraHari77 wants to merge 5 commits into
Conversation
…_tests_verification
…_tests_verification
…_tests_verification
There was a problem hiding this comment.
Pull request overview
This PR updates the Drools DMN TCK runner’s expected-result parsing for Decision Service test cases to account for implicit type conversion, specifically the date → date and time scenario that can change the Decision Service declared output type and therefore how expected XML values should be parsed.
Changes:
- Adds Decision Service–aware logic to select the expected output type when implicit conversion (DATE → DATE_TIME) applies.
- Introduces helpers to locate a Decision Service by name and to detect the implicit conversion compatibility case.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+159
to
+165
| // For Decision Services, check if implicit type conversion applies | ||
| DecisionServiceNode decisionService = getDecisionServiceByName(testSuiteContext, testCase.getInvocableName()); | ||
| DecisionNode decisionNode = testSuiteContext.getDMNModel().getDecisionByName(decisionName); | ||
|
|
||
| expectedType = isTypeCompatibleForImplicitConversion(decisionService.getResultType(), decisionNode.getResultType()) | ||
| ? decisionService.getResultType() : decisionNode.getResultType(); | ||
| expectedResult = parseType(testCaseResultNode.getExpected(), expectedType); |
Comment on lines
+423
to
+427
| private DecisionServiceNode getDecisionServiceByName(DroolsContext ctx, String name) { | ||
| return ctx.getDMNModel().getDecisionServices().stream() | ||
| .filter(ds -> ds.getName().equals(name)) | ||
| .findFirst().orElse(null); | ||
| } |
Comment on lines
+433
to
+438
| private boolean isTypeCompatibleForImplicitConversion(DMNType dsOutputType, DMNType decisionOutputType) { | ||
| return dsOutputType instanceof SimpleTypeImpl dsSimpleType && | ||
| dsSimpleType.getFeelType() == BuiltInType.DATE_TIME && | ||
| decisionOutputType instanceof SimpleTypeImpl decisionSimpleType && | ||
| decisionSimpleType.getFeelType() == BuiltInType.DATE; | ||
| } |
Contributor
|
@gitgabrio FYI |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR intends to address the issue while evaluating decisionservice results when implicit conversion is present.
When a decision body returns a date, the engine is permitted to implicitly convert it to date and time if the surrounding context (e.g., the Decision Service's declared output type) requires it.
Only the date → date and time implicit conversion changes the declared output type of the Decision Service (from date to date and time), which forces the TCK runner to parse the expected XML value differently. All other DMN implicit conversions (singleton list unwrapping, number coercion, etc.) leave the declared type unchanged, so the existing parsing logic already handles them correctly.