relation filter naming conflict leaks into unrelated schema generation instead of failing startup

[dilame]

Repro

https://github.com/dilame/ouchmyfinger

Versions

• postgraphile@5.0.0-rc.10
• graphile@5.0.0-rc.6
• postgraphile-plugin-connection-filter@3.0.0-rc.3
• @graphile/simplify-inflection@8.0.0-rc.5

Expected

A naming conflict in relation-derived filter fields should stay local to the conflicting type/fields.

If the schema cannot be built safely, the process should fail clearly during startup.

Actual

With this pair of columns on bonus.campaign:

wagering_requirement_id integer references wagering.requirement(id),
wagering_requirement_id_to_void integer references wagering.requirement(id)

postgraphile-plugin-connection-filter hits a naming conflict:

A naming conflict has occurred - two entities have tried to define the same key 'wageringRequirement'.

The important part is not the naming conflict itself.

The problem is that the conflict leaks out and breaks unrelated schema generation / introspection behavior instead of failing the process clearly.

In my case, adding one column in one table effectively broke unrelated GraphQL fields across the backend. The process still started, so this surfaced only as broken runtime behavior plus a warning in logs.

Why this matters

A local schema-generation failure like this should be explicit and fatal at startup.

If startup failed, the previous working process would have stayed running in Kubernetes and the problem would have been immediately diagnosable from deploy logs.

Instead, the service came up in a degraded state and it was not obvious where to look.