Skip to content

Error reporting when microgrid API is misconfigured #443

Open

Description

@stefan-brus-frequenz

What happened?

We wanted to run some FCR prequalification tests on a set of batteries. These batteries had been moved to a separate instance of the microgrid API. When running the actor, we were unable to start, because we got the error "Component tree is not a graph!". It appears to be thrown from here:

if not nx.is_tree(self._graph):

Initially, we could not find anything wrong with the component graph itself, since we verified it using the connections endpoint of the microgrid API. It was then pointed out to us that there existed a component, which was not connected to any other components. After removing this component, the error went away.

What did you expect instead?

Ideally, the error reporting here should be more detailed, to avoid debugging sessions that lead to false conclusions. Something like component ID #X has no connections and is a dangling component would have saved us a lot of effort here.

Affected version(s)

v0.20.0

Affected part(s)

Core components (data structures, etc.) (part:core), Microgrid (API, component graph, etc.) (part:microgrid)

Extra information

No response

Activity

  1. added
    priority:❓We need to figure out how soon this should be addressed
    type:bugSomething isn't working
    part:coreAffects the SDK core components (data structures, etc.)
    part:microgridAffects the interactions with the microgrid
    on Jun 16, 2023
  2. added
    priority:lowThis should be addressed only if there is nothing else on the table
    and removed
    priority:❓We need to figure out how soon this should be addressed
    on Jun 16, 2023
  3. thomas-nicolai-frequenz commented on Jun 16, 2023

    @thomas-nicolai-frequenz

    I suggest to not throw an error and have the entire SDK fail but rather throw a warning and ignore unconnected component(s). It can always happen that someone misconfigures the tree. However, there is a lot of problems with this because it might also be that we end up with two or more isolated trees. Hence, we have to handle a lot more potential error cases I'm afraid. This is tricky. Any thoughts anyone?

  4. shsms commented on Jun 16, 2023

    @shsms
    Contributor

    We use a 3rd-party library for building and verifying the graph, that doesn't seem to provide details of the sort, just a boolean is_tree method. We might have to do some custom graph traversal in the validation stage to give better error messages.

    @thomas-nicolai-frequenz especially in cases where we have deployments that are completely isolated from the grid, and we can't identify a main tree through a grid component. But in location with a grid connection, maybe we can just keep the tree with the grid connection and print warnings about the rest and ignore them?

    @stefan-brus-frequenz what kind of component was it that was dangling? was it a typo or was there a legitimate reason for it to be there and disconnected? could you give us some more context?

  5. thomas-nicolai-frequenz commented on Jun 16, 2023

    @thomas-nicolai-frequenz

    But in location with a grid connection, maybe we can just keep the tree with the grid connection and print warnings about the rest and ignore them?

    yeah that to me would be step one. I would not yet worry about the scenario of not having a grid connection even it will be a known limitation for now.

  6. removed
    part:coreAffects the SDK core components (data structures, etc.)
    on Jun 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    part:microgridAffects the interactions with the microgridpriority:lowThis should be addressed only if there is nothing else on the tabletype:bugSomething isn't working

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions