eugenegujing opened a new issue, #7146:
URL: https://github.com/apache/texera/issues/7146

   ### What happened?
   
   `FilledAreaPlotOpDesc.performTableCheck()` 
(`common/workflow-operator/src/main/scala/org/apache/texera/amber/operator/visualization/filledAreaPlot/FilledAreaPlotOpDesc.scala:108-130`)
 generates a Python guard that suppresses the chart when too many line groups 
have x-value sets disjoint from the others. The comment directly above it 
states the rule:
   
   ```scala
   // The function below checks whether there are more than 5 percents of the 
groups have disjoint sets of x attributes.
   ```
   
   The generated code does not implement that rule:
   
   ```python
   tolerance = (len(grouped) // 100) * 5
   ```
   
   The integer division runs before the multiplication, so the fraction is 
truncated away before it can be scaled: `40 // 100` is `0`, and `0 * 5` is `0`. 
The intended `(len(grouped) * 5) // 100` gives `2`. The two forms agree only 
when the group count is an exact multiple of 100:
   
   | line groups | current `(n // 100) * 5` | intended `(n * 5) // 100` |
   | --- | --- | --- |
   | 2 | 0 | 0 |
   | 19 | 0 | 0 |
   | 20 | 0 | 1 |
   | 40 | **0** | **2** |
   | 100 | 5 | 5 |
   | 200 | 10 | 10 |
   
   Below 100 groups the tolerance is therefore flat `0`, so a single disjoint 
group trips the guard (`count > tolerance` with `count == 1`) and the chart is 
replaced by the fallback HTML `"X attribute is not shared across all line 
groups"`. Below 20 groups both forms give `0`, which is correct — 1/19 = 5.3% 
does exceed 5% — so only charts with 20 or more line groups change behaviour.
   
   **Expected:** a chart with 40 line groups of which 1 is disjoint (2.5%) 
should render.
   **Actual:** it is suppressed, and the run reports success with no warning.
   
   Adjacent to #6728 (fixed by #6894) but a different defect — that PR 
corrected an `X_values` typo in this same block and did not touch the 
arithmetic, which is still wrong at HEAD.
   
   ### Minor observations in the same block
   
   None of these produces a wrong result today.
   
   - **No `break` once `error` is set.** The loop keeps walking the remaining 
groups after the verdict is final.
   - **`set(group[$x].unique())` is rebuilt twice per group** — once in the 
`elif` condition, once in the `union` call.
   - **The third `elif` is an `else` in disguise.** Its condition is the exact 
negation of the previous one, so it is always true when reached.
   
   ### How to reproduce?
   
   Build a Filled Area Plot with the "Line Group" field set, fewer than 100 
distinct groups, and one group whose x range does not overlap the others. The 
operator yields `"Plot is not available, because: X attribute is not shared 
across all line groups"` instead of the chart.
   
   Below is a example workflow I tested: three `PythonUDFSourceV2` → 
`FilledAreaPlot` branches that generate their own data, so no external dataset 
or file is needed. Import via Dashboard → Import, then Run.
   
   | branch | line groups | disjoint groups | rows | expected | actual at HEAD |
   | --- | --- | --- | --- | --- | --- |
   | A (control) | 40 | 0 | 400 | chart | chart |
   | **B** | 40 | 1 (2.5%) | 400 | **chart** | **suppressed — the defect** |
   | C (control) | 200 | 4 (2%) | 2000 | chart | chart |
   
   The two controls are what make branch B diagnostic. A proves the operator is 
configured correctly. C is the important one: its disjoint *ratio* (2%) is 
**lower** than B's (2.5%), yet it renders — purely because 200 crosses the 100 
threshold so the truncation does not annihilate the tolerance. That pins the 
cause on the integer division rather than on bad data or misconfiguration.
   
   ### Version/Branch
   
   1.3.0-incubating-SNAPSHOT (main)
   
   ### Commit Hash (Optional)
   
   _No response_
   
   ### What browsers are you seeing the problem on?
   
   _No response_
   
   ### Relevant log output
   
   ```shell
   
   ```


-- 
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]

Reply via email to