feat(workflow-operator): export the join and set operators as Python by kz930 · Pull Request #8506 · apache/texera

kz930 · 2026-09-11T03:53:37Z

What changes were proposed in this PR?

Six operators implement StandaloneCodeGenerator: the three joins and the three set operations. What they have in common is that they combine or compare tables rather than read what is inside a row.

#8340 keeps the operators that work on text. Aggregate and the sort family follow in #8709, and the samplers and control flow in #8710.

Review then found two places where the block answered a question the engine answers differently. The hash join asked pandas for a suffix, which appends once and then refuses the duplicate it just made, and let an outer join's holes cost an integer column its type.

Running the engine on those cases found the platform out of step with itself. HashJoin declared a right column's new name by checking only the left names, while the executor also avoids the other right names. So a right x beside a right x#@1 was declared as a second x#@1, and one value was lost. An unmatched right row in an outer join kept its raw names and landed in the left column. Both now go through one renaming rule in JoinUtils.

The shared table then found one more. In a right or full outer join on keys both sides name alike, the engine writes an unmatched right row's key into the left key column, and the export left it empty. The engine had its own half: an unmatched right key named like a left payload column landed in that payload. The export now fills the key, and the engine leaves it out of the payload.

The set operations matched rows the way pandas does. The engine's HashSet compares rows with Scala's ==, under which NaN equals nothing, and hashes them by each double's bits, which tell 0.0 from -0.0. The export now selects rows by a key that follows both rules.

A probe worker that received no build rows could not name an unmatched right row's columns, because it read the left names off the first build row. This happens when the left input is empty or no left key hashes to that worker. The runtime now records each input port's declared schema on the executor before the port finishes (OperatorExecutor.inputSchemas, filled in EndChannelHandler), and the probe reads the left names from it. This is the Scala counterpart of what #8766 does for Python operators.

Any related issues, documentation, discussions?

Part of #8325, step 11a; #8709 and #8710 follow. That issue lists the set in order.

The set operations and joins keyed on a null or a NaN need the nullable dtypes #8704 reads an Arrow file into. Without it a null and a NaN share a slot and both behave as they did before, so this PR is no worse on its own and only complete alongside that one.

Closes #8505, the task this change is the whole of.

How was this PR tested?

Each operator asserts the block it emits in its own spec. The interval join reads its keys off the merged frame rather than writing over an input column that shares a temporary's name.

The join cases the review named run in the verify tables of #8363, which put the same input through the engine and through the script and compare the two. What those tables cannot reach stays here as executed tests: a null kept apart from a NaN in the set operations and the join key. HashJoinProbeOpExecSpec pins the platform fixes.

Each set operation's spec runs its native executor and the export over NaN, signed-zero, finite and null rows. HashJoinProbeOpExecSpec covers an empty build side, and EndChannelHandlerSpec checks that the schema is in place before the operator finishes the port.

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

Generated-by: Claude Code (Claude Opus 5)

🤖 Generated with Claude Code

Seventeen operators implement the trait: the three joins, the three set operations, Aggregate, the sort family, Split, the two samplers, and If, Dummy and Sleep. What they have in common is that they rearrange rows rather than read what is inside one. A sampler decides per row whether to keep it, so which rows survive is fixed by the exact sequence java.util.Random produces. Seeding Python's own generator selects a different set, and the script would then report a different sample than the workflow it came from, so SamplingHelpers transcribes the generator rather than approximating it. Split out of apache#8340 on review, which had grown past what one reading can hold. That change keeps the operators that work on text, and the cast transcription they share. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

github-actions · 2026-09-11T03:54:08Z

Automated Reviewer Suggestions

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

Contributors with relevant context: @aglinxinyuan, @Yicong-Huang, @eugenegujing
You can notify them by mentioning @aglinxinyuan, @Yicong-Huang, @eugenegujing in a comment.

github-actions · 2026-09-11T03:57:12Z

⚠️ Benchmark changes need a look

🟢 2 better · 🔴 2 worse · ⚪ 11 noise (<±5%) · 0 without baseline

Compared against main 05c19a4 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 · Run

	config	throughput	MB/s	latency	max Δ latest / 7d
🔴	bs=10 sw=10 sl=64	403	0.246	23,752/36,647/36,647 us	🔴 +6.4% / 🔴 +179.2%
🟢	bs=100 sw=10 sl=64	859	0.525	114,716/128,386/128,386 us	🟢 -28.4% / 🔴 +40.9%
⚪	bs=1000 sw=10 sl=64	963	0.588	1,036,244/1,093,363/1,093,363 us	⚪ within ±5% / 🔴 +23.3%

Baseline details

Latest main 05c19a4 from same runner

config	metric	PR	latest main	7d avg	Δ latest	Δ 7d
bs=10 sw=10 sl=64	throughput	403 tuples/sec	393 tuples/sec	931.98 tuples/sec	+2.5%	-56.8%
bs=10 sw=10 sl=64	MB/s	0.246 MB/s	0.24 MB/s	0.569 MB/s	+2.5%	-56.8%
bs=10 sw=10 sl=64	p50	23,752 us	24,022 us	10,818 us	-1.1%	+119.6%
bs=10 sw=10 sl=64	p95	36,647 us	34,444 us	13,127 us	+6.4%	+179.2%
bs=10 sw=10 sl=64	p99	36,647 us	34,444 us	16,504 us	+6.4%	+122.0%
bs=100 sw=10 sl=64	throughput	859 tuples/sec	822 tuples/sec	1,210 tuples/sec	+4.5%	-29.0%
bs=100 sw=10 sl=64	MB/s	0.525 MB/s	0.502 MB/s	0.739 MB/s	+4.6%	-28.9%
bs=100 sw=10 sl=64	p50	114,716 us	113,375 us	85,326 us	+1.2%	+34.4%
bs=100 sw=10 sl=64	p95	128,386 us	179,278 us	91,092 us	-28.4%	+40.9%
bs=100 sw=10 sl=64	p99	128,386 us	179,278 us	102,379 us	-28.4%	+25.4%
bs=1000 sw=10 sl=64	throughput	963 tuples/sec	973 tuples/sec	1,240 tuples/sec	-1.0%	-22.3%
bs=1000 sw=10 sl=64	MB/s	0.588 MB/s	0.594 MB/s	0.757 MB/s	-1.0%	-22.3%
bs=1000 sw=10 sl=64	p50	1,036,244 us	1,021,864 us	840,622 us	+1.4%	+23.3%
bs=1000 sw=10 sl=64	p95	1,093,363 us	1,117,371 us	889,172 us	-2.1%	+23.0%
bs=1000 sw=10 sl=64	p99	1,093,363 us	1,117,371 us	931,615 us	-2.1%	+17.4%

Raw 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,496.80,200,128000,403,0.246,23752.32,36647.16,36647.16
1,100,10,64,20,2326.99,2000,1280000,859,0.525,114716.00,128385.94,128385.94
2,1000,10,64,20,20760.69,20000,12800000,963,0.588,1036243.59,1093363.22,1093363.22

codecov-commenter · 2026-09-11T03:57:37Z

Codecov Report

❌ Patch coverage is 58.82353% with 42 lines in your changes missing coverage. Please review.
✅ Project coverage is 91.75%. Comparing base (05c19a4) to head (82dd042).
⚠️ Report is 30 commits behind head on main.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
...exera/amber/operator/hashJoin/HashJoinOpDesc.scala	52.38%	10 Missing and 10 partials ⚠️
...ber/operator/intervalJoin/IntervalJoinOpDesc.scala	62.96%	2 Missing and 8 partials ⚠️
...amber/operator/set/intersect/IntersectOpDesc.scala	16.66%	5 Missing ⚠️
...ber/operator/set/difference/DifferenceOpDesc.scala	33.33%	2 Missing ⚠️
...ymmetricDifference/SymmetricDifferenceOpDesc.scala	33.33%	2 Missing ⚠️
.../texera/amber/core/executor/OperatorExecutor.scala	66.66%	1 Missing ⚠️
...ator/cartesianProduct/CartesianProductOpDesc.scala	50.00%	1 Missing ⚠️
.../amber/operator/hashJoin/HashJoinProbeOpExec.scala	92.85%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #8506      +/-   ##
============================================
- Coverage     92.17%   91.75%   -0.42%     
+ Complexity     5043     5026      -17     
============================================
  Files          1287     1271      -16     
  Lines         55799    56012     +213     
  Branches       7144     7267     +123     
============================================
- Hits          51434    51396      -38     
- Misses         2598     2784     +186     
- Partials       1767     1832      +65

Flag	Coverage Δ		*Carryforward flag
access-control-service	`77.44% <ø> (ø)`
agent-service	`99.54% <ø> (ø)`		Carriedforward from ac44d5b
amber	`85.75% <58.82%> (-1.15%)`	⬇️
computing-unit-managing-service	`64.02% <ø> (ø)`
config-service	`87.61% <ø> (ø)`
file-service	`82.29% <ø> (ø)`
frontend	`96.48% <ø> (+<0.01%)`	⬆️	Carriedforward from ac44d5b
notebook-migration-service	`83.77% <ø> (ø)`
pyamber	`98.54% <ø> (+0.06%)`	⬆️	Carriedforward from ac44d5b
workflow-compiling-service	`77.95% <ø> (ø)`

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

…he#8340) ### What changes were proposed in this PR? Six operators that read or rewrite a text column implement `StandaloneCodeGenerator`: Type Casting, Keyword Search, Substring Search, Unnest String, Regex and Dictionary Matcher. The sixteen that rearrange rows rather than read inside one are in apache#8506. Each is written against what its executor does rather than against what its name suggests, and the verification that came with the export runs both and compares them. Some of what that turned up is visible in the code: a cast reads the column's declared type rather than the value in front of it, because a hole widens an integer column to float and "6" would otherwise come back "6.0"; the 32-bit narrowing wraps for an integral source and saturates for a double, as `Long.toInt` and `Double.toInt` do; Dictionary Matcher's substring branch asks whether the cell sits inside a dictionary entry, which is the direction the executor tests and not the one the name suggests. `StandaloneHelpers` holds what these six share: a transcription of `AttributeTypeUtils`, emitted once near the top of a script rather than inlined per operator. A cast goes through `parseField(force = true)`, whose numeric branch is `java.text.NumberFormat`, so the engine reads "12abc" as 12 and "false" as false where Python's own conversions answer differently. Four of these operators change what they do, not only how they export. Regex, Substring Search and Unnest String answered a null cell by raising, which a generated script has no way to reproduce and no reason to: nothing in a column matches nothing, and unnests to no rows. They answer it that way now, and their specs say so. Keyword Search states which keywords its query parser will take, which a user had no way to know from the field alone. ### Any related issues, documentation, discussions? Part of apache#8325, 10 of 27; that issue lists the set in order. apache#8327 has since merged, so the trait is in place and this branch compiles on its own. The rows these operators add to the verification runner follow with the harness rather than as whole new files here. Closes apache#8074, closes apache#7548. Closes apache#8414, the task this change is the whole of. ### How was this PR tested? Each operator asserts the block it emits in its own spec. Type Casting's spec goes further: it runs the block it emits through a real Python and compares every answer against `AttributeTypeUtils`, so the two findings the review raised are held there, and that part does run on this diff's CI. Once the verification lands each operator is also run through the engine and through its generated script, on every configuration its schema offers, and the two answers compared; this branch is cut from main and does not carry that machinery, so those runs are not on this diff's CI. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Opus 5) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Xinyuan Lin <xinyual3@uci.edu>

carloea2

The Java random copy does not match Java integer overflow in next_int. Java rejects some values after the addition overflows, but this Python code always accepts them. This can select different rows for Split and Reservoir Sampling. Please copy the overflow check and add a seed that reaches the rejection case.

carloea2

There are more behavior gaps. If always defaults to the true branch because the exported script never receives the state. Sampling only matches one worker, while native runs with one random generator per worker. Aggregate CONCAT also writes Python boolean names instead of lowercase Java names. Reservoir size zero fails natively but silently returns empty in standalone. These cases need matching behavior or a clear unsupported error.

carloea2

More operators still differ. Sleep removes the delay. Timestamp sum fails and timestamp average returns the wrong type. Outer joins can turn integers into floats and fail chained name collisions. Dummy loses extra port routing. Sort order differs for NaN and some Unicode strings. Please add executed parity tests for these cases.

carloea2

Integer sum can return different data in the two paths. With 2147483647 and 1, native integer aggregation wraps to negative 2147483648, while pandas returns positive 2147483648 as a long. Please match the native result and add a boundary test.

carloea2

Set operations merge a null double and a real NaN. For example, if the left input has null and NaN and the right input has null, native Difference keeps the NaN row, but the exported code returns no rows. Please preserve this distinction and add a set operation test with both values.

carloea2

The same null and NaN problem also changes Join and Aggregate results. Left join keys null and NaN against a right null produce one native match but two exported matches. Grouping null and NaN with values 1 and 2 produces two native groups but one exported group totaling 3. Please cover keyed operators too.

…ational-and-sampling

The engine picks If's route from a State message on the Condition port, and the verification harness writes rows per port with no State channel, so a fixture can only ever reach the default route, True. The exported block reads the same decision from a global instead, which the spec can set, so both routes are run there: the rows leave by one output and the other comes back empty. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The engine compares with String.compareTo, which reads UTF-16 code units, while pandas compares by code point. They agree across the basic plane and differ only where a character above U+FFFF meets one in U+E000..U+FFFF, because the surrogate pair encoding the first holds units below that range. U+1F600 against U+FFFD is the shape of it: pandas reads the first as greater, the engine as smaller. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The transcribed nextInt carried its rejection sum as a Python integer, where Java lets an int overflow: a draw within bound of 2**31 wraps negative there and is taken again. Carrying it keeps the value Java throws away and shifts every later draw, which seed 12345 at bound 1000 reaches on draw 2126624. It also never refused a bound of zero, which Reservoir Sampling hands it when the reservoir holds nothing. The engine ends the run there; the script answered with an empty table instead. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…ers them Four places where pandas is asked the same question and answers differently. SUM keeps the column's declared type, so an INTEGER sum is Java int arithmetic and wraps at 2**31 where pandas widens, and a TIMESTAMP sum is a timestamp built from the added epoch milliseconds where pandas refuses to reduce datetime64 at all. AVERAGE is declared DOUBLE whatever it reads, so a timestamp average is the mean of those milliseconds and not a timestamp. CONCAT folds with Java's toString, which spells a boolean in lower case. The first three need the declared type rather than the dtype pandas inferred: a holed INTEGER column arrives as a float, and an INTEGER and a LONG arrive alike. The schema-free form keeps pandas' own answers rather than guessing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

@1

…ger integral The engine appends "#@1" to a colliding right column until the name is free, so one that meets an already-suffixed column lands on "#@1#@1". The export asked pandas for `suffixes` instead, which appends once and then refuses the duplicate it just made, ending the run. Compute the rename the way HashJoinProbeOpExec computes it, the way the Cartesian product export already did, and hand the merge columns that no longer collide. An outer join also leaves holes, and pandas pays for a hole in an integer column by reading the whole column as float. The engine writes a null and the column stays INTEGER, so the declared integer columns are read back as the nullable integer that says the same thing. Only the declared type can say which those are, and without a schema the widening stands. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The reasoning behind each fix was written twice, once in the commit that made it and again beside the line. Keep the half a reader needs to follow the code and drop the worked examples and the derivations. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The engine puts a null last whichever way a key points, and compares a NaN above every number, so a NaN goes last ascending and first descending. The export asked for na_position="last", which is right for the null and wrong for the NaN on the way down. Sort each key in three tiers instead: whether the value is missing, always ascending; whether it is a NaN, following the key; then the value. A column read into a numpy dtype holds a null and a NaN in the same slot, and there both land in the missing tier, which is where they were before. Telling them apart needs the nullable dtypes the Arrow source now reads into. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…d paths The engine reads a missing value and a stored NaN as two different values, so a difference keeps the NaN row a null row does not cancel, a join matches the missing key and not the NaN one, and a group keyed on each stays two groups. Each is run on the nullable dtype an Arrow file is read into, which is the only place the two are distinct. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

kz930 · 2026-09-18T20:15:07Z

Fixed in this PR: next_int's overflow rejection, a reservoir bound of zero, the INTEGER sum wrap, CONCAT's lower-case boolean, the join's rename and its integer column, and the NaN sort. If now has a spec that runs both routes. The null and NaN cases were the Arrow read rather than the operators, so #8341 reads the nullable dtypes instead, and Difference, the hash join and Aggregate each carry your case as a run test.

Four I would push back on. Dummy never overrides getPhysicalOp, so it cannot execute at all and has no routing to lose. Sleep's delay never reaches the output. Sampling is seeded with the worker count by the engine, and one process can only state one seed. A sorted string parts only where a character above U+FFFF meets one in U+E000..U+FFFF, since the engine reads UTF-16 code units and pandas reads code points.

Your two newest both reproduce here. Fixing them now.

carloea2

The new timestamp aggregation helpers assume the integer values are nanoseconds. With a microsecond column containing 2024-01-01, Sum returns 1970-01-20 17:21:07.200 instead. The nanosecond sum also overflows before conversion: six copies of 2024-01-01 return a date in 1709 instead of 2293. I reproduced both with pandas 2.2.3. Please convert each value to epoch milliseconds before aggregating and test both resolutions.

…the engine does The probe looks each key up in a HashMap under Scala's ==, where a NaN finds nothing, while merge paired NaN with NaN. Merge on codes that follow the engine's equality instead, each NaN taking one of its own. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

kz930 · 2026-10-14T03:26:16Z

@carloea2 One more case from your keyed-operator finding: two NaN keys were still treated as equal, while the engine never matches them. Hash Join now lets a NaN key match nothing (fa07950), and Aggregate in #8709 gives each NaN key its own group (14d7de2).

carloea2

The empty-build join fix passes, including colliding payload names and differently named keys. All 101 focused operator tests and 13 EndChannelHandler tests pass, with formatting clean. The original NaN and signed-zero set reproductions also pass. The remaining CI failure is LoopIntegrationSpec, covered by #8938. Code looks good. Leaving the draft status unchanged.

… the engine does IntervalJoinOpExec compares a timestamp by getTime, so two moments in the same millisecond are one point to it, and a left key just past the upper bound but inside its millisecond still joins. The export compared the full resolution and dropped those rows. Floor the two keys and the bound to the millisecond for the comparison, adding the bound before it is cut. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

kz930 · 2026-10-15T01:12:51Z

@carloea2 One more commit since your approval: Interval Join now compares timestamps by the millisecond, as the engine does (c59c02f).

…e, as the engine does An INTEGER bound is an Int sum: the engine cuts the constant to 32 bits and the sum wraps past Int.MaxValue, where pandas held the column as int64 and did neither. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

kz930 · 2026-10-15T17:25:33Z

@carloea2 One more: Interval Join now adds an INTEGER constant as an Int sum, cut to 32 bits and wrapping as the engine does (f4004e8).

…l clock, as the engine does The executor adds the constant to toLocalDateTime and reads the sum back with Timestamp.valueOf, so a day across a daylight-saving change is 23 or 25 hours and a month counts from the local date. The export added it to the UTC wall clock. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

kz930 · 2026-10-15T22:55:40Z

@carloea2 One more: Interval Join now adds a time interval on the machine's wall clock and reads it back in the machine's zone, as the engine does, so a day across a daylight-saving change is 23 or 25 hours (2036f15). It calls the zone helpers from #8597, so its Python tests pass once #8597 lands.

carloea2

The 76 operator tests, 14 EndChannelHandlerSpec tests and formatting pass with #8597 and #9003 supplied. A cross-operator timestamp regression still fails: two controls pass and both clock-change cases fail.

sbt -batch 'WorkflowOperator/testOnly *ReviewIntervalWallClockSpec -- -oDF'

This compares the native IntervalJoinOpExec with emitted code fed through the shared source timestamp reader, not a full connected workflow.

…ipt is handed A source already hands the script a timestamp as the machine's wall clock, so labelling it UTC and converting it again moved the bound by the local offset. The interval is now added to that wall clock as it stands, and the keys and the bound are read back into instants as Timestamp.valueOf reads them. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…the exported script _texera_set_row_keys, _texera_set_select and _texera_join_codes explained themselves in Python comments, which every exported script with a set operator or a Hash Join printed. The notes now sit in Scala, one line per function. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…exported script Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

carloea2

The daylight-saving finding is fixed. The 64 focused join and set tests pass, including the original four source-reader wall-clock probes. All 14 EndChannelHandlerSpec tests and scalafmtCheckAll pass too. Tested with the shared source and timestamp prerequisites supplied. CI remains red and must clear before merge.

…ared helper The shared helper also reads a wall clock in the hours around 1900-01-01 at the offset the engine does, where the old one was a whole offset off. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…odes Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

… comments Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…ed key codes Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

kz930 · 2026-10-26T22:19:59Z

@carloea2 Since your review, Hash Join and the set operators match keys with the shared _texera_key_codes, and Interval Join reads its wall clocks with the shared helper. Its exported Python also carries no comments now. Could you take another look?

carloea2

Intersect still differs from the engine for unequal input schemas.

…ared differently The engine compares a row's schema before its values, so left x:DOUBLE=1 and right y:DOUBLE=1 share no row. The export compared values only and kept x=1. It now emits an empty frame when the two input schemas differ. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

kz930 · 2026-11-04T21:07:16Z

@carloea2 Inputs with differing schemas now yield no rows, matching the engine. Could you take another look?

carloea2

Retested Intersect with different column names and types, plus NaN, signed zero, null and empty inputs. Native and exported results agree; all 45 focused Scala tests pass.

aglinxinyuan

LGTM!

…t's schema Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

kz930 mentioned this pull request Sep 11, 2026

feat(workflow-operator): export the operators that work on text #8340

Merged

github-actions Bot added feature common labels Sep 11, 2026

github-actions Bot assigned kz930 Sep 11, 2026

kz930 mentioned this pull request Sep 11, 2026

A workflow cannot be taken out of Texera as a script that runs on its own #8325

Open

20 of 31 tasks

kz930 marked this pull request as draft September 11, 2026 05:55

carloea2 suggested changes Sep 18, 2026

View reviewed changes

kz930 and others added 2 commits September 18, 2026 11:31

Merge remote-tracking branch 'upstream/main' into feat/standalone-rel…

ab530db

…ational-and-sampling

kz930 mentioned this pull request Sep 18, 2026

test(verify): hand-write the configurations a schema cannot describe #8363

Draft

kz930 and others added 7 commits September 18, 2026 12:26

Merge branch 'main' into feat/standalone-relational-and-sampling

c381bec

carloea2 suggested changes Sep 18, 2026

View reviewed changes

kz930 mentioned this pull request Oct 13, 2026

feat(workflow-operator): keep the rows Distinct's engine keeps for NaN and signed zero #8975

Draft

carloea2 approved these changes Oct 14, 2026

View reviewed changes

kz930 marked this pull request as ready for review October 15, 2026 01:12

kz930 marked this pull request as draft October 15, 2026 22:57

carloea2 suggested changes Oct 23, 2026

View reviewed changes

Comment thread ...erator/src/main/scala/org/apache/texera/amber/operator/intervalJoin/IntervalJoinOpDesc.scala Resolved

kz930 and others added 3 commits October 23, 2026 14:43

feat(workflow-operator): keep the sampling helper's notes out of the …

d183c31

…exported script Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

carloea2 approved these changes Oct 24, 2026

View reviewed changes

kz930 and others added 4 commits October 25, 2026 03:14

feat(workflow-operator): match Hash Join's keys with the shared key c…

770bbdc

…odes Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

feat(workflow-operator): keep Interval Join's exported Python free of…

24d5d9b

… comments Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

feat(workflow-operator): select the set operators' rows with the shar…

9d7468d

…ed key codes Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Merge remote-tracking branch 'upstream/main' into pr8506

f7b7527

kz930 marked this pull request as ready for review November 2, 2026 22:08

carloea2 suggested changes Nov 4, 2026

View reviewed changes

Comment thread ...operator/src/main/scala/org/apache/texera/amber/operator/set/intersect/IntersectOpDesc.scala Resolved

carloea2 approved these changes Nov 4, 2026

View reviewed changes

aglinxinyuan approved these changes Nov 5, 2026

View reviewed changes

Comment thread ...a/org/apache/texera/amber/engine/architecture/worker/promisehandlers/EndChannelHandler.scala Resolved

docs(engine): say plainly why the end-of-channel handler sets the por…

82dd042

…t's schema Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Conversation

kz930 commented Sep 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What changes were proposed in this PR?

Any related issues, documentation, discussions?

How was this PR tested?

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

Uh oh!

github-actions Bot commented Sep 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Automated Reviewer Suggestions

Uh oh!

github-actions Bot commented Sep 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

⚠️ Benchmark changes need a look

Uh oh!

codecov-commenter commented Sep 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

carloea2 left a comment

Choose a reason for hiding this comment

Uh oh!

carloea2 left a comment

Choose a reason for hiding this comment

Uh oh!

carloea2 left a comment

Choose a reason for hiding this comment

Uh oh!

carloea2 left a comment

Choose a reason for hiding this comment

Uh oh!

carloea2 left a comment

Choose a reason for hiding this comment

Uh oh!

carloea2 left a comment

Choose a reason for hiding this comment

Uh oh!

kz930 commented Sep 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

carloea2 left a comment

Choose a reason for hiding this comment

Uh oh!

kz930 commented Oct 14, 2026

Uh oh!

carloea2 left a comment

Choose a reason for hiding this comment

Uh oh!

kz930 commented Oct 15, 2026

Uh oh!

kz930 commented Oct 15, 2026

Uh oh!

kz930 commented Oct 15, 2026

Uh oh!

carloea2 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

carloea2 left a comment

Choose a reason for hiding this comment

Uh oh!

kz930 commented Oct 26, 2026

Uh oh!

carloea2 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

kz930 commented Nov 4, 2026

Uh oh!

carloea2 left a comment

Choose a reason for hiding this comment

Uh oh!

aglinxinyuan left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

kz930 commented Sep 11, 2026 •

edited

Loading

github-actions Bot commented Sep 11, 2026 •

edited

Loading

github-actions Bot commented Sep 11, 2026 •

edited

Loading

codecov-commenter commented Sep 11, 2026 •

edited

Loading

kz930 commented Sep 18, 2026 •

edited

Loading