[ZachFara]

What changed

tools/eval/github_tasks.py gets 1 more verified GitHub task, for 7 in all. Zach wants 20, so this is well short. I stopped at the turn budget and kept the bar where it was.

Task	Repo (license)	Upstream release (PyPI date)	upstream_change
gh-mloda-duckdb-join-alias	mloda-ai/mloda (Apache-2.0)	duckdb 2.0.0, 2026-10-21	duckdb-2.0-join-alias-after-new-select

• Pairs: 0. The new key has one task. mloda now has two tasks, under different upstream_change keys (polars join order and this one).
• Timing:
  • The upstream change is Move Relational API to BindStatement duckdb/duckdb-python#697, "Move Relational API to BindStatement". It was opened 2026-10-19 and merged as 0eeca76, authored and committed 2026-10-20. That is after the June 2026 cutoff and one day before the 2.0.0 release.
  • Its PR text states the behaviour: "After a join, column names are the engine's; an input alias stops resolving once a step started a new SELECT."
  • Issue DuckdbRelation __len__ and append_columns fail on DuckDB 2.0 mloda-ai/mloda#2395 was opened 2026-10-30. Its fix, #2405, was squash-merged 2026-10-30.
• Squash merge: base_commit is the squash commit's only parent, b407188.
• Setup: uv pip install --exclude-newer=... -e .[duckdb], then the duckdb==2.0.0 and pytest==9.1.1 pins. The .venv is 219 MB, mostly pyarrow and duckdb. That is slightly over the 200 MB guideline. It is in the same range as the polars tasks, and the record's comment says so.
• Fix: it changes code. append_columns projects the row number out of the join before ordering, instead of ordering the joined relation by "__l__".<rn>.
• Laid over and run: the fix's relation_test_mixin.py is laid over, but only the new test runs (test_append_columns_keeps_column_and_row_order).
  • The issue's other half, __len__ calling the removed fetchone(), is left out, because its error names its own fix (rel.limit(1).fetchall()).
  • Other mixin tests that call len() also fail at the base for that reason, but they are not in test_command.
• Hard-set: not claimed. The error doesn't name its fix, but I didn't test whether the obvious fix fails.

Base failing output (containerized)

Run	Result
Base, duckdb 2.0.0	1 failed
Fix, duckdb 2.0.0	1 passed
Base, duckdb 1.5.6	1 passed (previous version, checked)

Key lines:

mloda_plugins/compute_framework/base_implementations/duckdb/duckdb_relation.py:234: in append_columns
    result = joined.order(f'"__l__".{qrn}').project(keep)
E           _duckdb.BinderException: Binder Error: Referenced table "__l__" not found!
E           Candidate tables: "JOIN_RELATION_c09e101d76a70cbb"

The traceback ends in duckdb's guarded wrapper (duckdb/_relation.py).

The runs went through a .scratch/ helper that calls repos.materialize, repos.prepare and repos.run_tests with container.run, the same steps agent_eval.py check runs. Containers ran one at a time, none were left behind, and --on-host was never used.

Cause-word checks

• Cause words (after review):
  • bindstatement
  • bind statement
  • starts a new select
  • started a new select
  • 2.0
• All but 2.0 are non-version words. 2.0 is already in the expected version set, so there are no new version words.
• Dropped on review:
  • the alias phrases (alias stops resolving, alias no longer resolves, drops the join alias and the like): they restate the binder error. A fix that only re-aliases would say "the __l__ alias no longer resolves".
  • bare new select: a workaround says "wrap the join in a new SELECT".
  • Bare alias was never a cause word: the laid-over mixin has a whole "Alias" section, and the base source uses set_alias.
• Why these forms:
  • bind statement doesn't match "Binder Error"; bare bind would.
  • starts a new select needs its final "s", so "start a new select" in a fix doesn't match.
• Checked with grading v2's mentions (re-run for the new words on a fresh containerized base run) against:
  • the whole captured base output (46 lines);
  • the whole laid-over relation_test_mixin.py at the fix sha (334 lines);
  • the base duckdb_relation.py and sql_base_relation.py (git show b407188:... from the repo cache);
  • the symptom words (append_columns, Referenced table, BinderException, Binder Error), in both directions;
  • the names append_columns, append_column, _select_ordered, guarded, __len__, order, project, join and the test's name.
• Result: 0 hits.
• Leak review: I read the whole laid-over file. It has no comment, docstring or test name about DuckDB versions, aliases, SELECT boundaries or binding. The new test's name (..._keeps_column_and_row_order) describes only the behaviour. The fix's source comment states the cause ("DuckDB 2.0 drops the join aliases once order() is applied"), but the agent never sees the fix tree.

Rejected candidates (this batch)

• DuckDB 2.0: unfinished execute() results block relation reads, and CI has no 2.0 job mloda-ai/mloda#2406 / #2408 (duckdb 2.0, an unfinished execute() result blocks relation reads): the fix changes only a test, CI, tox and docs.
• SqlBaseRelation.window does not keep input row order for partitioned windows on DuckDB 2.0 mloda-ai/mloda#2393 / #2394 (duckdb 2.0 partitioned windows reorder rows): a cause word would repeat the row-order symptom ("row order" was rejected before). The fix also bundles unrelated engine and typed-input changes.
• Refuse comparison operators called by name, which DuckDB 2.0 fails on internally lakana-labs/lakana#293 / #316 (duckdb 2.0 operators called by name): a new guard refusal. The test fails at the base on any duckdb, so it doesn't depend on the version.
• Engine: pyproject stops allowing DuckDB 2.0 until the engine passes on it, and streamed results stream on both KratosDataGod/KratosForge#1340 / #1342 (duckdb 2.0 streaming reader): 100 MB repo with Spark and Snowflake test surfaces. The fix is a pin plus a broad engine change.
• Fix adds and drops failing on pandas 3.1 when no starter has played tefirman/fantasyfb#130 and etl_checks: dead_money_errors raises on an empty table under pandas 3.1, CI red benjamininja/Python-PowerBI-DynastyFantasyFootball#259 / #260 (pandas 3.1 Series.map on an empty str selection keeps the str dtype):
  • The upstream change, ENH: use _cast_pointwise_result in ExtensionArray.map pandas-dev/pandas#64801 ("use _cast_pointwise_result in ExtensionArray.map"), merged 2026-04-16, before the cutoff.
  • fantasyfb's new test comment also hints at the fix.
  • benjamininja has no detectable license (NOASSERTION).
• Make Selector.unique([]) independent of the pandas version facebookresearch/nevergrad#1727 (pandas 3.1 itertuples over no columns): the fix changes no test.
• fix: skip validation step for an empty plan and unblock CI on pandas 3.1 holoviz/lumen#2236: an unbound-variable bug, not caused by pandas 3.1.
• Make large-type normalization lossless and fix pandas 3 breakages fugue-project/triad#146: a broad pandas 3 rework, mostly from 3.0 (before the cutoff).
• GFQL fallback drops nullable 64-bit ID matches with pandas 3.1 / NumPy 2.5 graphistry/pygraphistry#2254 / #2255 (nullable 64-bit IDs on pandas 3.1 / NumPy 2.5): large repo, and the issue says the cause between pandas and NumPy isn't isolated.
• networkx 3.7 search: only noise and networkx's own bugs; random_lobster's removal was deprecated earlier.

From the brief and PRs #164, #165, #167 and #168: not re-checked.

Why

Ticket: MIT-618 (batch 7), the GitHub-task eval. These are real post-cutoff tasks for the arms run.

How it was tested

• Containerized runs of the new task: base and fix on duckdb 2.0.0, and base on 1.5.6, as described above.
• server/tests/test_eval_grader.py and server/tests/test_eval_repos.py pass.
• make check passes after merging origin/feature/eval-setup (already up to date).

Learned

• duckdb 2.0's Python relational API was rewritten in duckdb-python#697 (merged 2026-10-20). Its PR body lists the deliberate behaviour changes, and their BEHAVIOR.md holds the full list. It is a good map for duckdb 2.0 mining beyond the result-API removals: aliases after a new SELECT, bare strings as values, lazy parameterised sql(), distinct().project(), filter after limit, and query() leaving no view.
• duckdb 2.0's fetchone() / fetchmany() removal errors name their own fix ("Use rel.limit(1).fetchall() instead"). When a fix PR mixes that with a subtler break, run only the subtler test.
• pandas 3.1 entries in its whatsnew are often merged months before the 3.1.0 release. Check the PR's merge date: ExtensionArray.map keeping the Arrow/str dtype (pandas#64801) merged 2026-04-16, so its downstream breaks don't qualify.
• mloda with -e .[duckdb] installs about 219 MB (pyarrow and duckdb), slightly over the 200 MB guideline.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Qc1CQTb8r67J32HpkhS43y