test(verify): run the source operators, and report what is covered - #8364
Draft
kz930 wants to merge 6 commits into
Draft
test(verify): run the source operators, and report what is covered#8364kz930 wants to merge 6 commits into
kz930 wants to merge 6 commits into
Conversation
A source reads a file rather than an upstream port, so it is configured from a file the runner writes rather than from a table, and the variants follow the configuration: a CSV with a header and without, an encoding per charset. Two reports come with it. One prints which operators run and which are withheld and why, so the state of the set is a command rather than a claim. The other parses every generated script and fails on one that a hostile column name would break, which is a whole class of defect a comparison cannot see. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
Automated Reviewer SuggestionsBased on the
|
This was referenced Sep 2, 2026
…ady are It routes a source to the source runner and asks the escaping check for its findings, and the coverage report in turn reads the operators it discovered. Split across two changes those references point both ways, and neither compiles until both land whatever order they land in. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The spec printed a tier per operator, a per-kind tally, and every withheld run with its reason. That is a progress report: it read the same dispositions the run itself reads and asserted nothing about them, so it could only ever say what the run had already decided. What it did assert stays: a small set of operators that must not become unrunnable. They take the shared table as it is and nothing about them is hard to run, so one turning up flagged means something upstream of the disposition broke. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #8364 +/- ##
============================================
- Coverage 94.11% 94.10% -0.02%
- Complexity 4811 4858 +47
============================================
Files 1197 1203 +6
Lines 48813 48967 +154
Branches 5906 5930 +24
============================================
+ Hits 45939 46079 +140
+ Misses 1420 1419 -1
- Partials 1454 1469 +15
*This pull request uses carry forward flags. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Two comments here restated what the code beside them shows: the three tiers a source dispatches through, which `canRun` and `flagReason` already spell out, and this spec's own repetition of the runner's dispatch, which belongs to the runner. What replaces them says what each file is for, once. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
carloea2
approved these changes
Sep 4, 2026
carloea2
left a comment
carloea2
left a comment
Contributor
There was a problem hiding this comment.
The source verification and coverage checks look good.
kz930
marked this pull request as draft
September 4, 2026 17:12
The translator names a variable per output PORT, not per reader, so a workflow that draws two charts from one upstream hands both the same name. An operator that drops rows into it, or assigns a column through it, changes what the other branch reads. Ten operators did, and every one of them passed: a fixture with a single branch has nothing to notice it with. `StandaloneInputCheck` reads the generated code instead of waiting for a run to disagree, and reports all three spellings: the assignment, the `inplace=True`, and the rebinding that looks local but renames the shared variable. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`in1df.loc[:, "c"] = v` writes to the input exactly as `in1df["c"] = v` does, and the pattern read only the plain subscript, so an operator would have passed for choosing the accessor. What it still cannot see is a mutation through another name: bind the frame to something else first and the writes below are invisible to anything reading the code. The scaladoc says so rather than leaving the check looking airtight. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
carloea2
approved these changes
Sep 4, 2026
carloea2
left a comment
carloea2
left a comment
Contributor
There was a problem hiding this comment.
The new check catches direct changes to input frames. Looks good.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changes were proposed in this PR?
A source reads a file rather than an upstream port, so it is configured from a
file the runner writes rather than from a table, and the variants follow the
configuration: a CSV with a header and without, an encoding per charset.
Two reports come with it. One prints which operators run and which are
withheld and why, so the state of the set is a command rather than a claim.
The other parses every generated script and fails on one that a hostile column
name would break, which is a whole class of defect a comparison cannot see.
Any related issues, documentation, discussions?
Part of #8325, 20 of 21; that issue lists the set in order.
Closes #8426, the task this change is the whole of.
How was this PR tested?
The tests in this change cover it. The whole set is exercised together once the last piece lands: every operator run through the engine and through its generated script, and the two answers compared.
Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Opus 5)