Skip to content

Conversation

@lukedegruchy
Copy link
Contributor

  • Capture warnings as well as errors from CQL evaluation results.

@github-actions
Copy link

Formatting check succeeded!

@codecov
Copy link

codecov bot commented Nov 24, 2025

Codecov Report

❌ Patch coverage is 62.96296% with 10 lines in your changes missing coverage. Please review.
✅ Project coverage is 73.67%. Comparing base (9ad539f) to head (3dd7103).

Files with missing lines Patch % Lines
...e/common/CompositeEvaluationResultsPerMeasure.java 72.22% 2 Missing and 3 partials ⚠️
...measure/common/MeasureEvaluationResultHandler.java 44.44% 5 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##             master     #840      +/-   ##
============================================
- Coverage     73.68%   73.67%   -0.01%     
  Complexity      277      277              
============================================
  Files           576      576              
  Lines         27159    27183      +24     
  Branches       3459     3462       +3     
============================================
+ Hits          20013    20028      +15     
- Misses         5431     5438       +7     
- Partials       1715     1717       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

* When a warning or info is produced while evaluating, we capture the errors generated in this object, which can be rendered per Measure evaluated.
* @return {@code Map<IIdType, List<String>>}
*/
public Map<MeasureDef, List<String>> getWarningsPerMeasure() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The documentation says this is capturing warnings or infos, but that distinction is not preserved, is this intentional? Should there be a way to indicate warning vs info?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not without CQL changes. I'm fine to go ahead and do that, but what's the use case?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean CQL engine changes, or CQL content changes? We're reworking the engine APIs now, so if you mean that this would be good feedback. :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What Bryn is asking for is not possible without CQL changes to pass down infos separately to the multi-lib CQL evaluation result class.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, so can we do that? It would be wrong (imo) to return as a "warning" something that was an "info", and vice versa.

// We may get several errors for a given measure
private final Map<MeasureDef, List<String>> errorsPerMeasure;
// We may get several warnings for a given measure
private final Map<MeasureDef, List<String>> warningsPerMeasure;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There can be more information coming back from a message in CQL than just the message, it may have additional information, should we also expose that information?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't expose it for errors either, and this will require CQL changes. What are you looking to capture?

* When a warning or info is produced while evaluating, we capture the errors generated in this object, which can be rendered per Measure evaluated.
* @return {@code Map<IIdType, List<String>>}
*/
public Map<MeasureDef, List<String>> getWarningsPerMeasure() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, so can we do that? It would be wrong (imo) to return as a "warning" something that was an "info", and vice versa.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants