Multi-output submodel with wrong number of LHS outputs leaks a cryptic MethodError

Open Beginner friendly
#310 0 comments 0 reactions 0 assignees View on GitHub

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

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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ReactiveBayes/GraphPPL.jl

All issues in ReactiveBayes/GraphPPL.jl

Similar issues

More Julia issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.