Source customization type_names.prefix is not applied to *_aggregate_bool_exp types

Version Information

Server Version: v2.50.0 (also present in v2.50.1 changelog — no related fix) CLI Version (for CLI related issue): n/a (metadata applied via API)

Environment

OSS (Community Edition), self-hosted via Docker.

What is the current behaviour?

When a source is configured with customization.type_names.prefix, the prefix is applied to most generated GraphQL types, but not to the aggregation-predicate family:

• <table>_aggregate_bool_exp
• <table>_aggregate_bool_exp_bool_and
• <table>_aggregate_bool_exp_bool_or
• <table>_aggregate_bool_exp_count

These four are emitted with the bare table name. What makes it look like an oversight rather than a design decision: the fields inside those very types are prefixed correctly.

From the introspected schema of an instance whose source uses type_names.prefix: bluefable_ (the type name is bare, its fields are not):

input booking_aggregate_bool_exp {
  bool_and: booking_aggregate_bool_exp_bool_and
  bool_or: booking_aggregate_bool_exp_bool_or
  count: booking_aggregate_bool_exp_count
}

input booking_aggregate_bool_exp_bool_and {
  arguments: bluefable_booking_select_column_booking_aggregate_bool_exp_bool_and_arguments_columns!
  distinct: Boolean
  filter: bluefable_booking_bool_exp
  predicate: Boolean_comparison_exp!
}

Everything else for the same table is prefixed as configured: bluefable_booking_bool_exp, bluefable_booking_select_column, bluefable_booking_set_input, and so on.

What is the expected behaviour?

*_aggregate_bool_exp and its _bool_and / _bool_or / _count companions should follow the same source customization as every other generated type, i.e. bluefable_booking_aggregate_bool_exp.

The practical consequence of them not doing so: two sources in one instance cannot both have a table with the same name and an array relationship to it, even though both sources are fully customized with distinct namespaces and distinct type prefixes. Adding such a relationship fails schema building with:

Found conflicting definitions for GraphQL type ...

Per-source prefixes exist precisely to make same-named tables across sources safe, so this is a real hole in that guarantee: relationships, not just naming, become unavailable.

How to reproduce the issue?

1. Add two Postgres sources, A and B, each with customization — distinct root_fields.namespace and distinct type_names.prefix (e.g. a_ and b_).
2. Create a table named booking in both sources, plus a parent table in each (e.g. guest), and track them all.
3. In source A, add an array relationship guest.bookings -> booking. Schema builds fine, booking_aggregate_bool_exp appears in the schema — unprefixed.
4. In source B, add the same array relationship guest.bookings -> booking. Metadata application fails with Found conflicting definitions for GraphQL type, because booking_aggregate_bool_exp is already taken by source A.

Note that steps 1–2 alone are fine: the conflict only appears once an array relationship makes Hasura generate the aggregation-predicate types.

Screenshots or Screencast

n/a — the introspection excerpt above shows it directly.

Please provide any traces or logs that could help here.

The error surfaces on metadata application / schema build as Found conflicting definitions for GraphQL type "<table>_aggregate_bool_exp". In our case the instance hosts seven unrelated sources, each with its own namespace and prefix; two of them have a booking table, and the second array relationship to it is what triggers the failure.

Any possible solutions/workarounds you're aware of?

1. HASURA_GRAPHQL_EXPERIMENTAL_FEATURES=hide_aggregation_predicates — works (the conflicting types are no longer generated), but it is instance-wide: aggregation predicates disappear for every source, including unrelated projects sharing the instance. Not viable for us.
2. Renaming the table via custom_name in the source's table configuration, restoring the previous API surface with custom_root_fields. This is the shape of a workaround we're considering, since type names are derived from the (custom) table name — but it changes the names of all types for that table, which leaks into every document that references an input type.
3. Not using array relationships to the conflicting table at all (computing aggregates through a view instead). This is what we do today; it avoids the conflict rather than solving it.

A proper fix would simply route these four type names through the same customization path as the rest.

Keywords

aggregate_bool_exp, type_names prefix, source customization, Found conflicting definitions, aggregation predicates, array relationship, multiple sources same table name