Repository navigation
invalid graphml import path is not hardened (can crash or fail without proper feedback) #373
Description
Import path for GraphML is brittle on malformed files. If XML is invalid or partially broken, parser path can blow up and we don’t always surface a clean, actionable error to the user.
This should be defensive: parser should reject cleanly, import handler should catch and show a proper “invalid graphml” message every time.
Repro
-
take any .graphml
-
break XML intentionally (missing closing tag etc.)
-
import it
-
watch behavior / console
what expected:
graceful failure + clear error shown to user
actual:
runtime failure / inconsistent behavior, weak error handling
Activity
GREENRAT-K405 commentedon Mar 28, 2026
@avinxshKD nice catch but a small suggestion from my side if you don't mind, please make sure the parsers are not too strict, it's okay if something is wrong on the side of code for graphml file as long as it can import the functional workflow.
I did this mistake in past where @pradeeban sir suggested this. Thanks for contribution :D
GREENRAT-K405 commentedon Mar 28, 2026
BTW, will be happy to collaborate if you have any ideas for any big features!
pradeeban commentedon Mar 28, 2026
Yes, we don't want to be too strict. That is also a risk to fail, given we are supporting directed hypergraphs. But it is ok in any case. We can always go back and fix.
avinxshKD commentedon Mar 28, 2026
@pradeeban Agreed, we can always revisit and adjust.
The intent was just predictable failure handling (Invalid GraphML file.), not stricter parsing rules. So we're good
avinxshKD commentedon Mar 28, 2026
Yeah sure, sounds good
pradeeban commentedon Mar 28, 2026
There is also this real challenge: We have not sufficiently analyzed what type of graphs we want to support. What we know is, we support a sub-set of directed hypergraphs, basically those who follow <src, [dest]> format. Means, a hyper-edge connects a source node to one or many destination nodes. This is more complex than validating a directed graph.
avinxshKD commentedon Mar 28, 2026
@pradeeban agreed actually. I think we should lock the supported hypergraph contract first (effectively <src, [dest]> in our current model), then tighten validation against that. This PR only hardens malformed-XML failure handling
I can take a first pass on documenting the supported graph subset with a few accepted/rejected examples, If it makes sense :)
pradeeban commentedon Mar 28, 2026
@avinxshKD If you read the IEEE Access paper (the first CONTROL-CORE paper), it should give you some rationale (historic reasoning of sorts) on why we decided to go with a directed hypergraph (DHG) of <src, [dest]>. One source, many destinations. But it is really not necessary at this stage (unless you are really bored.)
avinxshKD commentedon Mar 28, 2026
@pradeeban Thanks, noted.... I’ll pick this up after my exams and share an update.