invalid graphml import path is not hardened (can crash or fail without proper feedback)

[avinxshKD]

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

[GREENRAT-K405]

@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]

BTW, will be happy to collaborate if you have any ideas for any big features!

[pradeeban]

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]

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.

@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]

BTW, will be happy to collaborate if you have any ideas for any big features!

Yeah sure, sounds good

[pradeeban]

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]

@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]

@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]

@pradeeban Thanks, noted.... I’ll pick this up after my exams and share an update.