v2.49.0
Added 2
- Add `--enable-relay` (`HASURA_GRAPHQL_ENABLE_RELAY`) flag to enable/disable Relay API, with default value `true` for Community/Enterprise and `false` for Cloud
- Add `HASURA_GRAPHQL_DISABLE_EVENTING` env var and `--disable-eventing` CLI flag to disable event triggers, scheduled events, cron event generator, and async actions on OSS/single-tenant build
Changed 3
- Promote Relay API to stable `/v1/relay` endpoint and deprecate `/v/1beta1/relay` endpoint
- Improve schema memory usage
- Set `--disable-eventing` flag on temporary HGE instances in `cli-migrations` v2 and v3 entrypoints so migration jobs no longer compete with eventing pollers for database resources
Fixed 1
- Fix MariaDB `update`/`delete` mutations failing with `Table 'temp_table_xxx' doesn't exist` by pinning CREATE/mutation/DROP lifecycle to one JDBC connection
Changelog
Bug fixes and improvements
Server
- feat: promote Relay API to stable
/v1/relayand deprecate/v/1beta1/relayendpoint. - feat: add the
--enable-relay(HASURA_GRAPHQL_ENABLE_RELAY) flag to enable/disable Relay API. You can disable Relay to reduce memory usage if it isn't required for your applications. The default value is:- Community/Enterprise:
truefor backward compatibility. - Cloud:
false. You need to enable it manually on the project settings.
- Community/Enterprise:
- enhancement: improvements to schema memory usage.
- feat: added
HASURA_GRAPHQL_DISABLE_EVENTINGenv var (and--disable-eventingCLI flag) to disable the entire eventing subsystem — event triggers, scheduled events, the cron event generator, and async actions — on the OSS / single-tenant build. Previously only multi-tenant cloud had this control. Thecli-migrationsv2 and v3 entrypoints now set this flag on their temporary HGE instance so migration jobs no longer compete with eventing pollers for database resources.
Data Connector
- fix: MariaDB `update`/`delete` mutations still failing with `Table 'temp_table_xxx' doesn't exist` on v2.48.15. The previous fix (#11473) ran the temp-table CREATE outside the transaction, which made the CREATE and the mutation body race over pooled connections; MariaDB temp tables are session-scoped, so when the mutation body got a different pooled connection the temp table was invisible. The full CREATE / mutation / DROP lifecycle now runs pinned to one JDBC connection. (Enterprise/cloud only)