Skip to content

Conversation

@Meklo
Copy link
Contributor

@Meklo Meklo commented Nov 21, 2025

PR Summary

Overview

This PR improves formula error handling in the spreadsheet view by ensuring all MathJS formula errors are properly displayed to users. Previously, generic errors were silently ignored, making it difficult to debug formula issues.

Changes Made

Core Logic Updates (column-mapper.ts)

  • Added isSingleSymbol() helper function: Uses MathJS parser to detect if a formula is a simple reference (e.g., columnA or object.property) versus a complex expression

  • Enhanced error handling:

    • Generic Error instances: Returns new generic error message for complex formulas
    • UX compromise: Single symbol references with missing data return undefined (no error shown) to avoid flooding the UI with "missing data" errors
      • Visual clarity of the spreadsheet: Missing data is fundamentally different from a broken formula. An empty cell when a reference to columnA has no value could be expected, while columnA + columnB * 2 failing indicates an actual problem that needs attention.
  • Targeted error suppression: Only simple references are filtered out. Any computation, operation, or function call will still display errors, ensuring users see problems with their actual formulas.

  • Null safety improvement: Added check to only validate non-null results from limitedEvaluate() to avoid displaying typing errors when the computed value is equal to undefined

Translation Updates

Added new generic error message :

  • spreadsheet/formula/error/generic: "Formula returns an error" / "La formule renvoie une erreur"

Solution Rationale

The chosen approach for filtering out missing data error was chosen over two alternatives:

Alternative 1: Parse Error Stack Strings to filter out targeted errors

  • String processing of error stacks is fragile and error-prone
  • Breaks easily with library updates or error message changes
  • Less maintainable and harder to test

Alternative 2: Remove @NonNull Lombok Annotations in Backend

  • Significant performance impact
    • Payload size increase: for example two-winding transformers dataset went from 7.6 MB → 9.5 MB on a big network
  • Risk of introducing functional bugs in other parts of the application that rely on non-null guarantees
  • Unacceptable trade-off for what is purely a display/error handling concern

Chosen Solution: Parse Formula Structure

The key improvement is using MathJS's AST parser to distinguish between simple data references and complex formulas. When a formula fails to evaluate, we parse it to determine if it's a single symbol (e.g., columnA) or accessor (e.g., object.property object.prop1['index']). If it is, we suppress the error and return undefined, treating it as missing data rather than a formula error.

Why this approach was chosen:

  • Frontend-only solution: Avoids backend changes that would impact payload size (+25% in tested datasets) and potentially break other application components expecting non-null guarantees.

  • Robust implementation: Uses MathJS's own parser rather than fragile string matching on error messages. The parser understands the formula structure, making the solution resilient to library updates and edge cases.

  • Performance: Parsing only occurs on error, so there's minimal overhead. The vast majority of successful formula evaluations bypass this logic entirely.

Going Further

A potential enhancement would be to add a per-column configuration option for error display behavior. This would allow users to choose between:

  • Filter missing data (current behavior): Simple references to missing data are hidden, only complex formula errors are shown
  • Display all errors: All evaluation failures are displayed, including missing data references

@sonarqubecloud
Copy link

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.

2 participants