Skip to content

fix(QuiverPlot, RangeSlider, v1.2): retarget numeric attributeTypeRules to real fields - #7011

Open
Yicong-Huang wants to merge 1 commit into
apache:release/v1.2from
Yicong-Huang:backport/6810-retarget-numeric-attributetyperules-to-r-v1.2
Open

fix(QuiverPlot, RangeSlider, v1.2): retarget numeric attributeTypeRules to real fields #7011
Yicong-Huang wants to merge 1 commit into
apache:release/v1.2from
Yicong-Huang:backport/6810-retarget-numeric-attributetyperules-to-r-v1.2

Conversation

@Yicong-Huang

Copy link
Copy Markdown
Contributor

What changes were proposed in this PR?

Backport of #6810 to release/v1.2, cherry-picked from 1c411de.

Source fix only. Test changes from #6810 were omitted (the touched specs do not exist on release/v1.2 or depend on main-only test infrastructure); only the source fix is carried over, per maintainer guidance.

Any related issues, documentation, discussions?

Backport of #6810. Originally linked #6795.

How was this PR tested?

Release-branch CI runs on this PR. Source change cherry-picked cleanly; test changes intentionally dropped.

Was this PR authored or co-authored using generative AI tooling?

Yes — backport prepared with Claude Code (mechanical cherry-pick + conflict resolution; the change itself is #6810 by its original author).

🤖 Generated with Claude Code

…real fields (apache#6810)

### What changes were proposed in this PR?

Both `QuiverPlotOpDesc` and `RangeSliderOpDesc` carry a class-level
`@JsonSchemaInject` `attributeTypeRules` block that constrains a field
named **`value`** to numeric types — but neither operator declares a
`value` field, so the rule matches nothing and **no type constraint is
applied**. The frontend column pickers therefore allow columns of any
type for fields the operator can only handle as numeric, which then
fails at chart time instead of being prevented up front.

**QuiverPlot** — fields are `x`, `y`, `u`, `v` (all required, no
`value`). All four are used as numeric vector coordinates in
`ff.create_quiver(x, y, u, v)`, and the generated code even
runtime-checks them with `isinstance(value, (int, float))`. So all four
must be numeric.

**RangeSlider** — fields are `Y-axis` and `X-axis` (no `value`). The
y-axis column is aggregated (`groupby(X-axis)[Y-axis].mean()/.sum()`),
so it must be numeric; the x-axis is only a grouping key and may be any
type.

**Fix:** retarget each rule to the real `@JsonProperty` field name(s):

```diff
 # QuiverPlot
-    "value": {
-      "enum": ["integer", "long", "double"]
-    }
+    "x": { "enum": ["integer", "long", "double"] },
+    "y": { "enum": ["integer", "long", "double"] },
+    "u": { "enum": ["integer", "long", "double"] },
+    "v": { "enum": ["integer", "long", "double"] }

 # RangeSlider
-    "value": {
+    "Y-axis": {
       "enum": ["integer", "long", "double"]
     }
```

### Any related issues, documentation, discussions?

Closes apache#6795

### How was this PR tested?

Added a regression test to each spec that reads the class-level
`@JsonSchemaInject` `json()` via reflection and asserts the
`attributeTypeRules` keys are the real fields (`x`/`y`/`u`/`v`;
`Y-axis`) — not `value` — and that each is constrained to the numeric
enum. Both fail on `main` (the key set is `{"value"}`) and pass with
this change.

```
sbt "WorkflowOperator/testOnly org.apache.texera.amber.operator.visualization.quiverPlot.QuiverPlotOpDescSpec org.apache.texera.amber.operator.visualization.rangeSlider.RangeSliderOpDescSpec"
...
Tests: succeeded 12, failed 0, canceled 0, ignored 0, pending 0
All tests passed.
```

### Was this PR authored or co-authored using generative AI tooling?

Generated-by: Claude Code (Claude Opus 4.8)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

(backported from commit 1c411de)

Signed-off-by: Kary Zheng <150742834+kz930@users.noreply.github.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
@Yicong-Huang Yicong-Huang added the release/v1.2 back porting to release/v1.2 label Jul 29, 2026
@Yicong-Huang
Yicong-Huang requested a review from xuang7 July 29, 2026 04:41
@github-actions

Copy link
Copy Markdown
Contributor

Automated Reviewer Suggestions

Based on the git blame history of the changed files, we recommend the following reviewers:

  • Contributors with relevant context: @aglinxinyuan
    You can notify them by mentioning @aglinxinyuan in a comment.

@codecov-commenter

codecov-commenter commented Jul 29, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 52.39%. Comparing base (fd5f487) to head (227d573).
⚠️ Report is 2 commits behind head on release/v1.2.

Additional details and impacted files
@@                Coverage Diff                 @@
##             release/v1.2    #7011      +/-   ##
==================================================
- Coverage           53.95%   52.39%   -1.56%     
- Complexity           1441     2493    +1052     
==================================================
  Files                 809     1077     +268     
  Lines               34144    42267    +8123     
  Branches             3448     4548    +1100     
==================================================
+ Hits                18421    22146    +3725     
- Misses              14815    18815    +4000     
- Partials              908     1306     +398     
Flag Coverage Δ *Carryforward flag
access-control-service 64.61% <ø> (ø)
agent-service 34.36% <ø> (ø) Carriedforward from fd5f487
amber 52.52% <ø> (-7.09%) ⬇️
computing-unit-managing-service 1.65% <ø> (ø)
config-service 56.06% <ø> (ø)
file-service 58.59% <ø> (ø)
frontend 47.19% <ø> (ø) Carriedforward from fd5f487
pyamber 90.87% <ø> (ø) Carriedforward from fd5f487
python 90.74% <ø> (ø) Carriedforward from fd5f487
workflow-compiling-service 58.69% <ø> (ø)

*This pull request uses carry forward flags. Click here to find out more.

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

🚀 New features to boost your workflow:
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@Yicong-Huang Yicong-Huang removed the release/v1.2 back porting to release/v1.2 label Jul 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants