You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@texera.apache.org by "aicam (via GitHub)" <gi...@apache.org> on 2026/08/26 17:46:01 UTC
[PR] fix(amber): hold result export to the same rules the export dialog applies [texera]
aicam opened a new pull request, #7994:
URL: https://github.com/apache/texera/pull/7994
### What changes were proposed in this PR?
The two result-export endpoints build their work entirely out of the request body — `workflowId`, `computingUnitId`, and the operator list — and the only thing either of them checks today is that the caller has read access to the workflow.
Two rules that the export dialog applies in the browser never reach the server:
- `GET /executions/{wid}/result/downloadability` computes, per operator, which datasets marked `is_downloadable = false` feed it, propagated downstream through the workflow graph. The dialog greys those operators out. Neither export endpoint consults the same map, so the restriction holds only for as long as the client cooperates.
- The dialog can only name the computing unit the workspace is attached to, but `getLatestExecutionID` selects on `(wid, cuid)` alone, so the unit id is otherwise just another body field.
So the same request is answered differently depending on which client sends it, and the dataset owner's downloadability setting is enforced in exactly one of the two places that act on it.
Both endpoints now share one `validateUserCanExportResult`, which keeps the existing workflow read-access check and adds the two missing rules:
1. read access to the workflow (unchanged);
2. read access to the computing unit named in the request, through `ComputingUnitAccess.getComputingUnitAccess` — a unit shared with the caller still exports, an unrelated one does not;
3. no requested operator carries data out of a non-downloadable dataset the caller does not own, using the same map the downloadability endpoint already returns to the UI.
The two new refusals answer `403` rather than the `401` the workflow check returns. The caller's session is valid in both new cases, and the frontend's `UnauthorizedHttpInterceptor` treats any `401` on an authenticated request as an expired session and logs the user out — the wrong outcome for a live session that merely asked for something it is not entitled to.
### Any related issues, documentation, discussions?
No issue. The per-operator restriction map and the dialog that consumes it already exist; this PR only makes the endpoints behind the dialog apply the same rule.
### How was this PR tested?
`WorkflowExecutionsResourceSpec`, six new cases covering both endpoints:
| Case | What it pins |
|---|---|
| computing unit the caller cannot reach (local + dataset) | `403` and the message, for a unit owned by another user |
| computing unit shared with the caller | a unit someone else owns but granted the caller `READ` on still exports — the predicate is access, not ownership |
| operator fed by a non-downloadable dataset (local + dataset) | `403` naming the blocking dataset; the local case asks for the *downstream* operator, so the restriction's propagation along the links is covered too |
| unrestricted operator of a restricted workflow | one restriction in a workflow does not close down the whole workflow |
Two existing cases named computing unit `0`, which no unit can have; they now insert a real unit so they still reach the code they were written for.
```
STORAGE_ICEBERG_CATALOG_TYPE=postgres sbt "WorkflowExecutionService/testOnly org.apache.texera.web.resource.dashboard.user.workflow.WorkflowExecutionsResourceSpec"
```
```
[info] Total number of tests run: 73
[info] Tests: succeeded 73, failed 0, canceled 0, ignored 0, pending 0
[info] All tests passed.
```
67 before, 73 after.
`Test/scalafmtCheck` and `Test/scalafix --check` pass.
### Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Claude Opus 5)
--
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: notifications-unsubscribe@texera.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(amber): hold result export to the same rules the export dialog applies [texera]
Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on PR #7994:
URL: https://github.com/apache/texera/pull/7994#issuecomment-5429482392
<!-- texera-benchmarks-comment -->
## ⚠️ Benchmark changes need a look
🟢 2 better · 🔴 1 worse · ⚪ 12 noise (<±5%) · 0 without baseline
> Compared against main `5de9bf9` benchmarked on **this same runner**, so the delta is largely free of cross-runner hardware noise. The "7d avg" column still reflects the gh-pages dashboard. Treat <±5% as noise unless repeated.
[Dashboard](https://apache.github.io/texera/dev/bench/) · [Run](https://github.com/apache/texera/actions/runs/32997080357)
| | config | throughput | MB/s | latency | max Δ latest / 7d |
|---|---|---:|---:|---:|---:|
| 🔴 | bs=10 sw=10 sl=64 | 558 | 0.34 | 17,037/22,915/22,915 us | 🔴 +6.0% / 🔴 +65.5% |
| 🟢 | bs=100 sw=10 sl=64 | 1,218 | 0.744 | 81,593/91,843/91,843 us | 🟢 -11.2% / 🟢 -10.1% |
| ⚪ | bs=1000 sw=10 sl=64 | 1,437 | 0.877 | 693,026/758,460/758,460 us | ⚪ within ±5% / 🟢 +19.9% |
<details><summary>Baseline details</summary>
Latest main `5de9bf9` from same runner
| config | metric | PR | latest main | 7d avg | Δ latest | Δ 7d |
|---|---|---:|---:|---:|---:|---:|
| bs=10 sw=10 sl=64 | throughput | 558 tuples/sec | 585 tuples/sec | 894.86 tuples/sec | -4.6% | -37.6% |
| bs=10 sw=10 sl=64 | MB/s | 0.34 MB/s | 0.357 MB/s | 0.546 MB/s | -4.8% | -37.7% |
| bs=10 sw=10 sl=64 | p50 | 17,037 us | 16,069 us | 11,139 us | +6.0% | +53.0% |
| bs=10 sw=10 sl=64 | p95 | 22,915 us | 24,033 us | 13,843 us | -4.7% | +65.5% |
| bs=10 sw=10 sl=64 | p99 | 22,915 us | 24,033 us | 16,839 us | -4.7% | +36.1% |
| bs=100 sw=10 sl=64 | throughput | 1,218 tuples/sec | 1,184 tuples/sec | 1,166 tuples/sec | +2.9% | +4.5% |
| bs=100 sw=10 sl=64 | MB/s | 0.744 MB/s | 0.723 MB/s | 0.711 MB/s | +2.9% | +4.6% |
| bs=100 sw=10 sl=64 | p50 | 81,593 us | 80,628 us | 87,509 us | +1.2% | -6.8% |
| bs=100 sw=10 sl=64 | p95 | 91,843 us | 103,461 us | 93,675 us | -11.2% | -2.0% |
| bs=100 sw=10 sl=64 | p99 | 91,843 us | 103,461 us | 102,153 us | -11.2% | -10.1% |
| bs=1000 sw=10 sl=64 | throughput | 1,437 tuples/sec | 1,460 tuples/sec | 1,198 tuples/sec | -1.6% | +19.9% |
| bs=1000 sw=10 sl=64 | MB/s | 0.877 MB/s | 0.891 MB/s | 0.731 MB/s | -1.6% | +19.9% |
| bs=1000 sw=10 sl=64 | p50 | 693,026 us | 687,406 us | 859,766 us | +0.8% | -19.4% |
| bs=1000 sw=10 sl=64 | p95 | 758,460 us | 770,591 us | 902,897 us | -1.6% | -16.0% |
| bs=1000 sw=10 sl=64 | p99 | 758,460 us | 770,591 us | 937,957 us | -1.6% | -19.1% |
</details>
<details><summary>Raw CSV</summary>
```csv
config_idx,batch_size,schema_width,string_len,num_batches,total_ms,total_tuples,total_bytes,tuples_per_sec,mb_per_sec,lat_p50_us,lat_p95_us,lat_p99_us
0,10,10,64,20,358.72,200,128000,558,0.340,17037.49,22915.06,22915.06
1,100,10,64,20,1641.46,2000,1280000,1218,0.744,81593.41,91842.78,91842.78
2,1000,10,64,20,13915.41,20000,12800000,1437,0.877,693026.49,758459.85,758459.85
```
</details>
--
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: notifications-unsubscribe@texera.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(amber): hold result export to the same rules the export dialog applies [texera]
Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on PR #7994:
URL: https://github.com/apache/texera/pull/7994#issuecomment-5429085426
<!-- backport-auto-label-report -->
### Backport auto-label report
This `fix:` PR was checked against each actively-supported release branch. `release/*` labels drive the post-merge backport, so add or remove one to change where this fix lands.
| Release branch | Analysis |
| --- | --- |
| ✅ `release/v1.2` | Change detected on this branch — label added; this fix is queued to backport here. Requested review from @xuang7. |
_[Auto-label run](https://github.com/apache/texera/actions/runs/32996017008)._
--
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: notifications-unsubscribe@texera.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(amber): hold result export to the same rules the export dialog applies [texera]
Posted by "Yicong-Huang (via GitHub)" <gi...@apache.org>.
Yicong-Huang commented on code in PR #7994:
URL: https://github.com/apache/texera/pull/7994#discussion_r4058798860
##########
amber/src/main/scala/org/apache/texera/web/resource/dashboard/user/workflow/WorkflowExecutionsResource.scala:
##########
@@ -794,6 +795,65 @@ class WorkflowExecutionsResource {
.entity(Map("error" -> "No sufficient access privilege.").asJava)
.build()
+ /** 403 rather than the 401 above, for a caller who *can* read the workflow but may not take
+ * this particular data out of it. The distinction is also operational: the frontend's
+ * UnauthorizedHttpInterceptor reads any 401 on an authenticated request as an expired
+ * session and logs the user out, which is the wrong outcome for a live session that simply
+ * asked for something it is not entitled to.
+ */
+ private def exportDeniedResponse(message: String): Response =
+ Response
+ .status(Response.Status.FORBIDDEN)
+ .`type`(MediaType.APPLICATION_JSON)
+ .entity(Map("error" -> message).asJava)
+ .build()
+
+ /** Authorizes one result-export request, for both the local and the dataset endpoint.
+ *
+ * Three things have to hold before results leave the system:
+ *
+ * 1. the caller can read the workflow the results belong to;
+ * 2. the caller can reach the computing unit that produced them — `getLatestExecutionID`
+ * selects on `(wid, cuid)` alone, so the unit is as much a caller-chosen key as the
+ * workflow id is;
+ * 3. no requested operator carries data from a dataset whose owner marked it
+ * non-downloadable. `getWorkflowResultDownloadability` hands the same map to the UI,
+ * which greys those operators out — but that is advice to a cooperating client, and
+ * both export endpoints are reachable directly.
+ *
+ * @return the response to send back, or None when the export may proceed
+ */
+ private def validateUserCanExportResult(
+ user: UserPojo,
+ request: ResultExportRequest
+ ): Option[Response] = {
+ if (!WorkflowAccessResource.hasReadAccess(request.workflowId, user.getUid)) {
+ Some(workflowAccessDeniedResponse)
+ } else if (
+ ComputingUnitAccess
+ .getComputingUnitAccess(request.computingUnitId, user.getUid)
+ .eq(PrivilegeEnum.NONE)
+ ) {
+ Some(exportDeniedResponse("No sufficient access privilege to the computing unit."))
+ } else {
+ val restrictions = getNonDownloadableOperatorMap(request.workflowId, user)
Review Comment:
**Must fix:**
This map is computed from `WORKFLOW.CONTENT`, the workflow's current JSON (`:132-136`). The rows released come from whatever `getLatestExecutionID` resolves, and that query joins on `WORKFLOW_VERSION.WID.eq(wid)` (`:103`), so it spans every version. The caller controls one input and not the other. Anyone with WRITE (the owner always, and the owner is who this control targets) can clear the locked scan's `fileName`, save, and re-post the same request. The old execution's results still resolve, and the recomputed map no longer names the operator. I would compute the map from the executed version, which `WorkflowVersionResource.applyPatch` already reconstructs, and make the three `Map.empty` returns (`:139`, `:148`, `:160`) deny. If that is too large for this PR, say so in the Scaladoc.
##########
amber/src/main/scala/org/apache/texera/web/resource/dashboard/user/workflow/WorkflowExecutionsResource.scala:
##########
@@ -794,6 +795,65 @@ class WorkflowExecutionsResource {
.entity(Map("error" -> "No sufficient access privilege.").asJava)
.build()
+ /** 403 rather than the 401 above, for a caller who *can* read the workflow but may not take
Review Comment:
**Advisory:**
`UnauthorizedHttpInterceptor` fires only on an `HttpErrorResponse` for a request carrying an `Authorization` header (`unauthorized-http-interceptor.service.ts:80-88`). That covers `/export/dataset`, not `/export/local`: `DownloadService` posts the latter as a hidden form into a hidden iframe (`download.service.ts:208-233`), so the interceptor never sees the response. On that endpoint the 403 body lands in the iframe, so a denied caller gets no feedback and the download simply never starts. Fixing that is outside this diff, but narrowing the comment to name the dataset endpoint costs one clause.
##########
amber/src/test/scala/org/apache/texera/web/resource/dashboard/user/workflow/WorkflowExecutionsResourceSpec.scala:
##########
@@ -211,12 +211,14 @@ class WorkflowExecutionsResourceSpec
getDSLContext
.deleteFrom(WORKFLOW_COMPUTING_UNIT)
- .where(WORKFLOW_COMPUTING_UNIT.UID.eq(testUserId))
+ .where(WORKFLOW_COMPUTING_UNIT.UID.between(testUserId, testUserId + 10))
Review Comment:
**Advisory:**
A question, not a retitle demand. `CONTRIBUTING.md`'s type table routes "a functionality or a form of support never existed and you are adding it" to `feat`, even when the docs already described it as present. Server-side enforcement of these two rules never existed, as the description says. Reading a security gap as a `fix` is defensible, and the table does not settle it. But the prefix is what the auto-label bot keys on: it has already labelled this PR `release/v1.2` and queued the backport. Two new 403 refusals headed for a patch release deserve a committer's explicit call.
##########
amber/src/test/scala/org/apache/texera/web/resource/dashboard/user/workflow/WorkflowExecutionsResourceSpec.scala:
##########
@@ -211,12 +211,14 @@ class WorkflowExecutionsResourceSpec
getDSLContext
.deleteFrom(WORKFLOW_COMPUTING_UNIT)
- .where(WORKFLOW_COMPUTING_UNIT.UID.eq(testUserId))
+ .where(WORKFLOW_COMPUTING_UNIT.UID.between(testUserId, testUserId + 10))
Review Comment:
**Must fix:**
The body says "No issue", with no `Closes #N`, no `#N` mention and no discussion link, so nothing is linked in the Development sidebar. `CONTRIBUTING.md` step 2 asks for an issue and consensus before development. Its minor typo and docs exception does not stretch to two new authorization refusals on public endpoints, queued for a release backport. Open an issue and promote the reference to `Closes #N`. Every other template section is filled, including the ASF generative-AI disclosure.
--
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: notifications-unsubscribe@texera.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(amber): hold result export to the same rules the export dialog applies [texera]
Posted by "Ma77Ball (via GitHub)" <gi...@apache.org>.
Ma77Ball commented on code in PR #7994:
URL: https://github.com/apache/texera/pull/7994#discussion_r4034516758
##########
amber/src/main/scala/org/apache/texera/web/resource/dashboard/user/workflow/WorkflowExecutionsResource.scala:
##########
@@ -857,22 +917,22 @@ class WorkflowExecutionsResource {
@Path("/result/export/dataset")
@RolesAllowed(Array("REGULAR", "ADMIN"))
def exportResultToDataset(request: ResultExportRequest, @Auth user: SessionUser): Response = {
- if (!WorkflowAccessResource.hasReadAccess(request.workflowId, user.getUser.getUid)) {
- workflowAccessDeniedResponse
- } else {
- try {
- val resultExportService =
- new ResultExportService(WorkflowIdentity(request.workflowId), request.computingUnitId)
- resultExportService.exportToDataset(user.user, request)
-
- } catch {
- case ex: Exception =>
- Response
- .status(Response.Status.INTERNAL_SERVER_ERROR)
- .`type`(MediaType.APPLICATION_JSON)
- .entity(Map("error" -> ex.getMessage).asJava)
- .build()
- }
+ validateUserCanExportResult(user.getUser, request) match {
Review Comment:
`validateUserCanExportResult` runs outside the try/catch here, whereas in `exportResultToLocal` (line 960) it runs inside one. Its DB calls (`getComputingUnitAccess`, `getNonDownloadableOperatorMap`) can throw, and on this endpoint that exception escapes uncaught instead of becoming the `{"error": ...}` 500 JSON body this endpoint returns for every other failure.
Why it matters: a transient DB error during authorization surfaces as a raw container 500 on `/export/dataset` but as a clean JSON 500 on `/export/local` -- inconsistent, and harder for the client to parse. This is not a regression (the old read-access check sat outside the try too), just a good moment to align the two endpoints; wrap the `match` in the existing try, or lift the shared try/catch around both.
Nit, optional.
##########
amber/src/test/scala/org/apache/texera/web/resource/dashboard/user/workflow/WorkflowExecutionsResourceSpec.scala:
##########
@@ -1668,4 +1727,111 @@ class WorkflowExecutionsResourceSpec
assert(response.getStatus == Response.Status.UNAUTHORIZED.getStatusCode)
}
+ // ─── export authorization beyond workflow read access ─────────────────────
+ // Read access to the workflow is not the whole gate: the execution is looked up by
+ // (wid, cuid), and an operator's results can carry data out of a dataset its owner
+ // marked non-downloadable. Both endpoints answer those two with a 403 — not the 401
+ // above, which the frontend's interceptor reads as an expired session.
+
+ private val computingUnitDenied = "No sufficient access privilege to the computing unit."
+
+ "export authorization" should "deny a download for a computing unit the caller cannot reach" in {
+ grantReadAccess()
+ val foreignUnit = insertComputingUnit(insertUser(testUserId + 2, "cu-owner@example.com").getUid)
+ insertExecution(cuid = foreignUnit.getCuid)
+
+ val response = resource.exportResultToLocal(
+ Json.stringify(
+ Json.toJson(exportRequest(List(OperatorExportInfo("op-1", "csv")), foreignUnit.getCuid))
+ ),
+ tokenFor(UserRoleEnum.REGULAR)
+ )
+ assert(response.getStatus == Response.Status.FORBIDDEN.getStatusCode)
+ assert(errorOf(response) == computingUnitDenied)
+ }
+
+ it should "deny an export to dataset for a computing unit the caller cannot reach" in {
+ grantReadAccess()
+ val foreignUnit = insertComputingUnit(insertUser(testUserId + 2, "cu-owner@example.com").getUid)
+ insertExecution(cuid = foreignUnit.getCuid)
+
+ val response = resource.exportResultToDataset(
+ exportRequest(List(OperatorExportInfo("op-1", "csv")), foreignUnit.getCuid),
+ session(testUser)
+ )
+ assert(response.getStatus == Response.Status.FORBIDDEN.getStatusCode)
+ assert(errorOf(response) == computingUnitDenied)
+ }
+
+ // Shared access, not ownership, is the predicate: a unit someone else owns but granted
+ // the caller READ on has to still export, or the check would break every shared unit.
+ it should "allow a download for a computing unit shared with the caller" in {
+ grantReadAccess()
+ val foreignUnit = insertComputingUnit(insertUser(testUserId + 2, "cu-owner@example.com").getUid)
+ grantComputingUnitAccess(foreignUnit.getCuid)
+ insertExecution(cuid = foreignUnit.getCuid)
+
+ val response = resource.exportResultToLocal(
+ Json.stringify(
+ Json.toJson(
+ exportRequest(
+ List(OperatorExportInfo("op-1", "csv"), OperatorExportInfo("op-2", "csv")),
+ foreignUnit.getCuid
+ )
+ )
+ ),
+ tokenFor(UserRoleEnum.REGULAR)
+ )
+ assert(response.getStatus == 200)
+ }
+
+ it should "deny a download of an operator fed by a non-downloadable dataset" in {
+ grantReadAccess()
+ val unit = insertComputingUnit()
+ insertExecution(cuid = unit.getCuid)
+ seedNonDownloadableWorkflow(testUserId + 3, "locked-owner@example.com")
+
+ // The downstream operator, not the scan itself: the restriction propagates along the
+ // links, and the data reaching downstreamB came out of the locked dataset.
+ val response = resource.exportResultToLocal(
+ Json.stringify(
+ Json.toJson(exportRequest(List(OperatorExportInfo("downstreamB", "csv")), unit.getCuid))
+ ),
+ tokenFor(UserRoleEnum.REGULAR)
+ )
+ assert(response.getStatus == Response.Status.FORBIDDEN.getStatusCode)
+ assert(errorOf(response).contains("LockedDS (locked-owner@example.com)"))
+ }
+
+ it should "deny an export to dataset of an operator fed by a non-downloadable dataset" in {
+ grantReadAccess()
+ val unit = insertComputingUnit()
+ insertExecution(cuid = unit.getCuid)
+ seedNonDownloadableWorkflow(testUserId + 3, "locked-owner@example.com")
+
+ val response = resource.exportResultToDataset(
+ exportRequest(List(OperatorExportInfo("scanA", "csv")), unit.getCuid),
+ session(testUser)
+ )
+ assert(response.getStatus == Response.Status.FORBIDDEN.getStatusCode)
+ assert(errorOf(response).contains("LockedDS (locked-owner@example.com)"))
+ }
+
+ // Only the operators carrying the restricted data are blocked; one restriction in the
+ // workflow must not close the whole workflow down.
+ it should "let an unrestricted operator of a restricted workflow through" in {
Review Comment:
The new suite covers the deny paths and the shared-unit allow path, but not the dataset-owner allow path that `getNonDownloadableOperatorMap` implements: its `isOwner` check skips datasets the caller owns, so an operator fed by the caller's *own* non-downloadable dataset must still export. This PR is what newly makes the export endpoints enforce that map, so the allow side deserves a pin too.
Why it matters: without it, a future change that dropped the `isOwner` exclusion, or otherwise over-blocked, would pass CI while silently breaking a workflow owner exporting results derived from their own non-downloadable dataset -- a real, common flow.
Suggested fix: add a case that seeds `LockedDS` owned by `testUser` (reuse `seedNonDownloadableWorkflow` with `testUser`'s uid/email) and asserts `exportResultToLocal` on `scanA` is not `FORBIDDEN`.
--
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: notifications-unsubscribe@texera.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(amber): hold result export to the same rules the export dialog applies [texera]
Posted by "codecov-commenter (via GitHub)" <gi...@apache.org>.
codecov-commenter commented on PR #7994:
URL: https://github.com/apache/texera/pull/7994#issuecomment-5429577853
## [Codecov](https://app.codecov.io/gh/apache/texera/pull/7994?dropdown=coverage&src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) Report
:x: Patch coverage is `86.66667%` with `4 lines` in your changes missing coverage. Please review.
:white_check_mark: Project coverage is 93.21%. Comparing base ([`5de9bf9`](https://app.codecov.io/gh/apache/texera/commit/5de9bf94766d441e7d1655bf326a9208dc6769a5?dropdown=coverage&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache)) to head ([`8090b24`](https://app.codecov.io/gh/apache/texera/commit/8090b240e70143f76d00fcd3d81c97c11a7d8452?dropdown=coverage&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache)).
:warning: Report is 1 commits behind head on main.
:white_check_mark: All tests successful. No failed tests found.
| [Files with missing lines](https://app.codecov.io/gh/apache/texera/pull/7994?dropdown=coverage&src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | Patch % | Lines |
|---|---|---|
| [...ard/user/workflow/WorkflowExecutionsResource.scala](https://app.codecov.io/gh/apache/texera/pull/7994?src=pr&el=tree&filepath=amber%2Fsrc%2Fmain%2Fscala%2Forg%2Fapache%2Ftexera%2Fweb%2Fresource%2Fdashboard%2Fuser%2Fworkflow%2FWorkflowExecutionsResource.scala&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache#diff-YW1iZXIvc3JjL21haW4vc2NhbGEvb3JnL2FwYWNoZS90ZXhlcmEvd2ViL3Jlc291cmNlL2Rhc2hib2FyZC91c2VyL3dvcmtmbG93L1dvcmtmbG93RXhlY3V0aW9uc1Jlc291cmNlLnNjYWxh) | 86.66% | [2 Missing and 2 partials :warning: ](https://app.codecov.io/gh/apache/texera/pull/7994?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) |
<details><summary>Additional details and impacted files</summary>
```diff
@@ Coverage Diff @@
## main #7994 +/- ##
=========================================
Coverage 93.21% 93.21%
- Complexity 4664 4670 +6
=========================================
Files 1175 1175
Lines 47646 47665 +19
Branches 5319 5324 +5
=========================================
+ Hits 44413 44433 +20
+ Misses 1752 1750 -2
- Partials 1481 1482 +1
```
| [Flag](https://app.codecov.io/gh/apache/texera/pull/7994/flags?src=pr&el=flags&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | Coverage Δ | | *Carryforward flag |
|---|---|---|---|
| [access-control-service](https://app.codecov.io/gh/apache/texera/pull/7994/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `81.00% <ø> (ø)` | | Carriedforward from [5de9bf9](https://app.codecov.io/gh/apache/texera/commit/5de9bf94766d441e7d1655bf326a9208dc6769a5?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) |
| [agent-service](https://app.codecov.io/gh/apache/texera/pull/7994/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `99.32% <ø> (ø)` | | Carriedforward from [5de9bf9](https://app.codecov.io/gh/apache/texera/commit/5de9bf94766d441e7d1655bf326a9208dc6769a5?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) |
| [amber](https://app.codecov.io/gh/apache/texera/pull/7994/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `89.33% <86.66%> (+0.01%)` | :arrow_up: | |
| [computing-unit-managing-service](https://app.codecov.io/gh/apache/texera/pull/7994/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `73.67% <ø> (ø)` | | Carriedforward from [5de9bf9](https://app.codecov.io/gh/apache/texera/commit/5de9bf94766d441e7d1655bf326a9208dc6769a5?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) |
| [config-service](https://app.codecov.io/gh/apache/texera/pull/7994/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `86.73% <ø> (ø)` | | Carriedforward from [5de9bf9](https://app.codecov.io/gh/apache/texera/commit/5de9bf94766d441e7d1655bf326a9208dc6769a5?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) |
| [file-service](https://app.codecov.io/gh/apache/texera/pull/7994/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `86.70% <ø> (ø)` | | Carriedforward from [5de9bf9](https://app.codecov.io/gh/apache/texera/commit/5de9bf94766d441e7d1655bf326a9208dc6769a5?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) |
| [frontend](https://app.codecov.io/gh/apache/texera/pull/7994/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `95.67% <ø> (ø)` | | Carriedforward from [5de9bf9](https://app.codecov.io/gh/apache/texera/commit/5de9bf94766d441e7d1655bf326a9208dc6769a5?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) |
| [notebook-migration-service](https://app.codecov.io/gh/apache/texera/pull/7994/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `79.31% <ø> (ø)` | | Carriedforward from [5de9bf9](https://app.codecov.io/gh/apache/texera/commit/5de9bf94766d441e7d1655bf326a9208dc6769a5?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) |
| [pyamber](https://app.codecov.io/gh/apache/texera/pull/7994/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `97.74% <ø> (ø)` | | Carriedforward from [5de9bf9](https://app.codecov.io/gh/apache/texera/commit/5de9bf94766d441e7d1655bf326a9208dc6769a5?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) |
| [workflow-compiling-service](https://app.codecov.io/gh/apache/texera/pull/7994/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `77.19% <ø> (ø)` | | Carriedforward from [5de9bf9](https://app.codecov.io/gh/apache/texera/commit/5de9bf94766d441e7d1655bf326a9208dc6769a5?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) |
*This pull request uses carry forward flags. [Click here](https://docs.codecov.io/docs/carryforward-flags?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) to find out more.
</details>
[:umbrella: View full report in Codecov by Harness](https://app.codecov.io/gh/apache/texera/pull/7994?dropdown=coverage&src=pr&el=continue&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache).
:loudspeaker: Have feedback on the report? [Share it here](https://about.codecov.io/codecov-pr-comment-feedback/?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache).
<details><summary> :rocket: New features to boost your workflow: </summary>
- :package: [JS Bundle Analysis](https://docs.codecov.com/docs/javascript-bundle-analysis): Save yourself from yourself by tracking and limiting bundle sizes in JS merges.
</details>
--
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: notifications-unsubscribe@texera.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(amber): hold result export to the same rules the export dialog applies [texera]
Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on PR #7994:
URL: https://github.com/apache/texera/pull/7994#issuecomment-5429028686
<!-- texera-reviewer-suggestion -->
### Automated Reviewer Suggestions
Based on the `git blame` history of the changed files, we recommend the following reviewers:
- **Contributors with relevant context:** `@aglinxinyuan`, `@tanishqgandhi1908`
You can notify them by mentioning `@aglinxinyuan`, `@tanishqgandhi1908` in a comment.
--
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: notifications-unsubscribe@texera.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org