Skip to content

test(frontend): cover combineValidation#6685

Open
Ma77Ball wants to merge 4 commits into
apache:mainfrom
Ma77Ball:test/combine-validation-spec
Open

test(frontend): cover combineValidation#6685
Ma77Ball wants to merge 4 commits into
apache:mainfrom
Ma77Ball:test/combine-validation-spec

Conversation

@Ma77Ball

Copy link
Copy Markdown
Contributor

What changes were proposed in this PR?

  • Add unit tests for the static ValidationWorkflowService.combineValidation reducer.
  • Cover empty input, all-valid, mixed valid/invalid message filtering, multi-invalid merging, and duplicate-key override.

Any related issues, documentation, discussions?

Closes: #6684

How was this PR tested?

  • Run: cd frontend && node --max-old-space-size=8192 ./node_modules/nx/dist/bin/nx.js test gui --watch=false --include=src/app/workspace/service/validation/validation-workflow.service.spec.ts, expect the suite passing.
  • Test-only change; no production code is modified.

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

Co-authored with Claude Opus 4.8 in compliance with ASF

@github-actions github-actions Bot added the frontend Changes related to the frontend GUI label Jul 21, 2026
@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.

@Yicong-Huang

Yicong-Huang commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

how come the coverage report is not generated on those frontend test only PRs?

cc @aglinxinyuan can you help investigate it?

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Pull request overview

Adds focused frontend unit test coverage for ValidationWorkflowService.combineValidation (a static reducer used by workflow/operator validation), ensuring expected behavior for validity aggregation and invalid-message merging.

Changes:

  • Added unit tests for combineValidation covering empty input, all-valid inputs, valid+invalid filtering, multi-invalid merging, and duplicate-key override behavior.
  • Updated imports in the existing spec to reference Validation/ValidationError types used by the new tests.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread frontend/src/app/workspace/service/validation/validation-workflow.service.spec.ts Outdated
Comment thread frontend/src/app/workspace/service/validation/validation-workflow.service.spec.ts Outdated
Comment thread frontend/src/app/workspace/service/validation/validation-workflow.service.spec.ts Outdated
@aglinxinyuan

Copy link
Copy Markdown
Contributor

Dug into this. The coverage is uploaded and fully processed on these PRs — the only thing missing is the last step, Codecov posting the PR comment. It's the tokenless upload path on fork PRs, not our codecov.yml or the diff.

These PRs are from forks, so GitHub doesn't hand secrets to the pull_request run (required-checks.yml correctly uses pull_request, not pull_request_target). CODECOV_TOKEN ends up empty — the frontend job log shows INPUT_CODECOV_TOKEN: blank — so the upload falls back to Codecov's tokenless path. Tokenless uploads are rate-limited, and when a batch of them lands together Codecov drops the comment/notify step for most commits. The report itself still processes to state: complete; only the comment is skipped.

It tracks almost perfectly with how many PRs were opened at once:

Time (UTC) opened together got comment
07-16 10:35 6 5/6
07-20 09:13 3 3/3
07-20 21:32 3 1/3
07-21 03:30 10 0/10

#6685 was in that 10-PR burst. #6687 was too and stayed silent for a day — until it picked up a merge main commit that re-ran CI, and the comment appeared ~7 min later. Re-running CI (or "Update branch") reliably brings it back.

Ruled out: not "no coverage change" (require_changes defaults to false, and several PRs in the dead burst did move coverage), not config (identical for every PR), not a missing base report (base commit is complete).

Two fixes:

  • Now — re-trigger CI on the affected PRs (Update branch / re-run the frontend job), and stagger PR creation instead of opening ~10 together.
  • Durable — move the Codecov upload to a workflow_run-triggered workflow: the pull_request build uploads the coverage/junit files as artifacts (no secrets, safe for fork code), and a follow-up workflow fires on completion in the base-repo context where CODECOV_TOKEN exists and does a tokenized upload. Authenticated uploads aren't rate-limited like tokenless, so comments post reliably even in bursts — it's Codecov's documented pattern for forks. Put up a PR for this: ci: route all Codecov flags through the deferred workflow_run upload #6730.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
aglinxinyuan added a commit to Ma77Ball/texera that referenced this pull request Jul 23, 2026
…pache#6730)

### What changes were proposed in this PR?

Route **every** Codecov flag's upload through a follow-up `workflow_run`
workflow instead of uploading inline from the `pull_request` build, so
fork PRs get authenticated (non-rate-limited) uploads and a reliable
Codecov PR comment.

**Problem.** A PR from a fork never receives `secrets.CODECOV_TOKEN`
(the build runs on `pull_request`, and GitHub withholds secrets from
fork runs). The inline `codecov-action` steps therefore fall back to
Codecov's *tokenless* path, which is rate-limited; under a burst of
fork-PR uploads Codecov still processes the report but silently drops
the PR comment (reported on apache#6685).

**Fix.**
- `build.yml`: each coverage job stages its reports as a
`codecov-<flag>` artifact via `.github/scripts/stage-codecov.sh`
(`coverage/` + `results/` + pr/sha/branch identifiers) instead of
uploading inline. The script preserves the directory tree so amber's ~8
same-basename module `jacoco.xml` don't collide. Staging is skipped on
backport builds (artifact-name collisions across the target matrix) and
pinned to the single producing leg for the dual-OS / multi-python jobs.
- `codecov-upload.yml`: a per-flag matrix runs on `workflow_run` after
**Required Checks**, in the base-repo context where `CODECOV_TOKEN` is
available. It downloads each artifact and re-uploads with the token,
using `directory:` scoping so Codecov's search finds every file per
flag.
- **Failure surfacing:** coverage uploads fail hard, and a
`notify-failure` job then comments on the PR (a link to the failed run +
the `run_id` to manually dispatch) — Codecov only self-comments on
success, so this covers the failure case. A delayed / no-runner run
posts nothing at all, which is itself the signal that the upload is
stuck.

Flags covered: frontend, amber, amber-integration (test-results only),
pyamber, agent-service, and the 6 platform services.

Why not batch into fewer calls: Codecov requires one upload per flag
(flags in a single upload apply to *all* its files, and carryforward —
which `codecov.yml` relies on — needs the flag set at upload time), with
no path-based auto-assignment, so the calls can't be collapsed without
dropping the per-flag / carryforward model. The token — not batching —
is what removes the tokenless rate-limit pressure.

### Any related issues, documentation, discussions?

Reported on apache#6685.

### How was this PR tested?

- `workflow_run` only triggers from the copy of the file on the default
branch, so `codecov-upload.yml` activates only after merge; it exposes a
`workflow_dispatch` (`run_id`) entry to validate against a finished
*Required Checks* run immediately after merge.
- `.github/scripts/stage-codecov.sh` was exercised locally: multi-module
glob → no basename collisions, single-file flags, and the empty-PR
(push) case.
- YAML validated for both workflows. The staging half runs in **this
PR's own CI**, so the `codecov-<flag>` artifacts can be inspected on
this run.
- Reviewed for coverage parity (every prior inline upload is still
staged + re-uploaded — nothing dropped), artifact-name collisions
(backport guard + per-leg pinning), and deferred-upload correctness
(empty-override omission, missing-artifact handling, `matrix.coverage`
gating).
- First-live-run check after merge: confirm each flag's test-results
(Test Analytics) JUnit files are discovered under `directory:` —
best-effort, and separate from the coverage report.

Since the deferred workflow can only activate on `main`, if anything is
off the whole change reverts as a single PR.

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

Yes.

Generated-by: Claude Code (Opus 4.8 [1M context])
@aglinxinyuan

Copy link
Copy Markdown
Contributor

Merged main to trigger coverage report.

@codecov-commenter

codecov-commenter commented Jul 23, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 75.38%. Comparing base (e2e4418) to head (168eca1).
⚠️ Report is 2 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files
@@             Coverage Diff              @@
##               main    #6685      +/-   ##
============================================
- Coverage     76.27%   75.38%   -0.90%     
+ Complexity     3452     3446       -6     
============================================
  Files          1161     1161              
  Lines         45917    45916       -1     
  Branches       5100     5100              
============================================
- Hits          35025    34615     -410     
- Misses         9327     9678     +351     
- Partials       1565     1623      +58     
Flag Coverage Δ *Carryforward flag
access-control-service 70.00% <ø> (ø) Carriedforward from fa075d1
agent-service 76.76% <ø> (ø) Carriedforward from fa075d1
amber 67.18% <ø> (-0.15%) ⬇️ Carriedforward from fa075d1
computing-unit-managing-service 20.49% <ø> (ø) Carriedforward from fa075d1
config-service 66.66% <ø> (ø) Carriedforward from fa075d1
file-service 67.21% <ø> (ø) Carriedforward from fa075d1
frontend 79.79% <ø> (-1.92%) ⬇️ Carriedforward from fa075d1
notebook-migration-service 78.94% <ø> (ø) Carriedforward from fa075d1
pyamber 92.15% <ø> (ø) Carriedforward from fa075d1
workflow-compiling-service 55.14% <ø> (ø) Carriedforward from fa075d1

*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.

@aglinxinyuan

Copy link
Copy Markdown
Contributor

Closing as it doesn't increase coverage: #6685 (comment)

@aglinxinyuan

Copy link
Copy Markdown
Contributor

Will reevaluate after fixing the Codecov Report.

@aglinxinyuan aglinxinyuan reopened this Jul 23, 2026
mengw15 pushed a commit to mengw15/texeraFork that referenced this pull request Jul 23, 2026
…he#6824)

### What changes were proposed in this PR?

Follow-up to apache#6730. The deferred `Codecov Upload` workflow hardcoded all
11 flags in its matrix and tried to download each from the source run.
On a label-gated PR — e.g. a frontend-only PR that only stages
`codecov-frontend` — the other 10 legs hit `##[error] Artifact not found
for name: codecov-<flag>`, which looks like a name mismatch; and because
the download used `continue-on-error: true`, a genuinely failed download
was swallowed, the leg went green, and `notify-failure` never fired.

**Fix:** add a `discover` job that lists the source run's *actual*
`codecov-*` artifacts and drives the upload matrix from that
(`fromJSON`), and drop `continue-on-error` on the download.

- **No more spurious errors** — only the flags the source run actually
built are processed; a frontend-only PR runs one clean leg.
- **Failures surface** — a listed artifact that then fails to download
or upload fails the leg, so `notify-failure` fires (previously it went
silently green).
- Also removes the hardcoded flag list, so adding a `platform` service
no longer needs a matching matrix row here.

Observed on the first live run after apache#6730 merged ([run
29984668372](https://github.com/apache/texera/actions/runs/29984668372),
triggered by a frontend-only PR's checks): `frontend` uploaded fine, but
10 legs logged `Artifact not found` for the label-gated flags and the
run still went green.

### Any related issues, documentation, discussions?

Follow-up to apache#6730 (reported on apache#6685).

### How was this PR tested?

- `workflow_run` only activates from the copy of the file on the default
branch, so this can't run on its own PR. Validated by YAML lint and an
adversarial review of the discover → upload → notify flow: empty-flags
cleanly skips (no failure, no notify), the dynamic `fromJSON` matrix
handles one or many flags, a download/upload failure now fails the leg
and fires `notify-failure`, `amber-integration` (results-only) skips the
coverage step via `hashFiles`, and the `workflow_dispatch` path resolves
the run id.
- The `workflow_dispatch` (`run_id`) entry remains for manual post-merge
validation against a finished *Required Checks* run.

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

Yes.

Generated-by: Claude Code (Opus 4.8 [1M context])
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

frontend Changes related to the frontend GUI

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add unit test coverage for combineValidation

5 participants