Tracing / instrumentation for RDL errors

Tracing / instrumentation for RDL errors

Posted by: seaninglis on 10 October 2025, 12:18 pm EST

• 

  seaninglis

  • Post Options:
  • Link
    Copy

  Posted 10 October 2025, 12:18 pm EST - Updated 11 October 2025, 4:41 am EST

  We have a lot of reports formats - 1000+ - which for one reason and another generate non-fatal error messages on rendering.

  These error are almost always errors or omissions in RDL expressions but it’s difficult to work back from the error generated in the console to the source of the incorrect / incomplete RDL expression, and they are so numerous it’s causing issues.

  For instance we see multiple errors of the form:

  can't access property "Eval", args[2] is undefined

  and this is always down to the 2nd branch of an IIF being omitted - fairly obvious.

  As well as there being a lot of reports, each report also have a lot of fields and expressions and these are frequently very heavily nested.

  Is there a way to link a console warning / error of this type to the source expression / report component that was it’s ultimate cause, or some additional level of logging we can turn on.

  I’ve done a batch of changes by loading the report definition into a good editor, filtering, and eyeballing the expressions to get to a batch of the culprits but it’s pretty hard work and I’m definitely missing a lot of them.

  Am I missing something obvious I can turn on to help with this?

  ETA: this is in 4.2, upgrading is on our list, but not an option at the moment.

• 

  anand.sinha

  

  • Post Options:
  • Link
    Copy

  Posted 13 October 2025, 4:09 am EST

  Hi Sean,

  Unfortunately, as far as I know, there is no inbuilt feature in ActiveReportsJS to auto-link runtime errors to their source RDL expressions.

  The best way to resolve such issues is to open the expressions manually one by one in the expression editor, as it displays any compile-time error or warning within itself.

  Another way would be to go through the report’s JSON and search for the expression tags, and go through the expressions in the JSON and check for any obvious errors.

  Regards,
  
  Anand

• 

  seaninglis

  • Post Options:
  • Link
    Copy

  Posted 13 October 2025, 1:51 pm EST

  Hi,

  Yes as I say, I’ve been extracting the JSON and reformatting and splitting expressions but there are many many such expressions.

  Loading each one into the editor and checking isn’t feasible, and these errors are not highlighted as errors in any case: the error is not reported when the IIF expression is edited and omits a clause but this does result in multiple console warnings, enough to impact performance and make other debugging all but impossible.

  Has this situation change in versions > 4.2 and, if not, how do I request that some new feature is added, or existing feature is surfaced to track these down?

  It’s hard to believe that whoever’s developing this doesn’t have something that can help.

  s

• 

  anand.sinha

  

  • Post Options:
  • Link
    Copy

  Posted 14 October 2025, 1:05 am EST

  Hi Sean,

  We understand the inconvenience you were caused by going through multiple expressions to eyeball any obvious mistakes.

  Unfortunately, no such enhancement has been added to track down the source or the control in which the exception occurs in version >4.2; therefore, we have raised a feature request to our development team to introduce this in a future release [Internal Tracking ID: ARJ-7625].

  We’ll keep you updated with any updates we get from the development team.

  In the meantime, can you share a sample report that has the replicable issue, so we can share it with our development team, such that in case this issue gets fixed, we can cross-check it with your sample.

  Thanks,
  
  Anand