Multi-output submodel with wrong number of LHS outputs leaks a cryptic MethodError
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 82/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- julia
- Domain
- machine-learning
Research direction
Start in src/graph_engine.jl at prepare_interfaces and compare the single-output validation around lines 1858-1873 with the multi-output path at lines 1875-1886. Run the relevant cases in test/multi_and_zero_output_tests.jl, especially line 76. Done means mismatched LHS and missing-interface counts raise a readable error and the test asserts that message.
Written by the indexing model from the issue text.
Description
Summary
Multi-output submodel calls ((a, b) ~ sub(x = x)) must have the number of LHS outputs
equal to the number of missing (un-named) interfaces. When they differ, the path falls
through to MethodError: no method matching make_node!(...) with no indication of the real
problem. The single-output path already validates this and raises a clear error
(src/graph_engine.jl:1858-1873); the multi-output path (1875-1886) does not.
Root cause
prepare_interfaces_multi (src/graph_engine.jl:1881-1886) builds a NamedTuple from
missing interfaces + LHS, without checking length(missing) == length(lhs). A mismatch
leaks a MethodError.
Repro / existing test
test/multi_and_zero_output_tests.jl:76 currently pins the confusing behaviour:
@test_throws "no method matching make_node!" create_model(main_mismatch()) do model, ctx ... end
Suggested fix
Add an explicit check in prepare_interfaces (Tuple-LHS) with a clear message:
if length(missing) != n_lhs
error("Submodel '$fform' expects $(length(missing)) output interface(s) but $(n_lhs) were provided on the LHS.")
end
Update the test to assert the readable message.
- Dominant language
- Julia
- Stars
- 46
- Forks
- 8
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from ReactiveBayes/GraphPPL.jl
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
ReactiveBayes/GraphPPL.jl#309 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
ReactiveBayes/GraphPPL.jl#308 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 76/100
ReactiveBayes/GraphPPL.jl#306 ·
-
`@warn` in apply_constraints! throws `UndefVarError: opt` when a node already has a form constraint Open
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
ReactiveBayes/GraphPPL.jl#305 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
ReactiveBayes/GraphPPL.jl#304 ·
All issues in ReactiveBayes/GraphPPL.jl
Similar issues
-
tagbot-manual
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
documentation
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Sienna-Platform/PowerSystems.jl#1800 ·
-
enhancement good first issue help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100