Skip to content

v2.49.4

Latest

Choose a tag to compare

@hasura-bot hasura-bot released this 08 Jul 14:34

Changelog

This is a patch release for v2.49.

Bug fixes and improvements

Server

  • Made catalog and PG source migrations idempotent by adding IF NOT EXISTS to all ADD COLUMN statements, preventing re-application failures when a migration was applied to the database but its version was not recorded.
  • Add a new option HASURA_GRAPHQL_WEBSOCKET_QUEUE_SIZE to bound the formerly unbounded internal queue used for sends on a websocket, set to 100 by default. Previously a very slow and long-lived client could in theory allow outgoing messages to pile up indefinitely. Now when the limit is reached the oldest message will be discarded. Users who don't use streaming subscriptions can consider setting this value to 1, which will have the effect of slow or delayed clients always pulling the freshest value. Eviction events can be monitored with the new hasura_websocket_messages_queued_total and hasura_websocket_messages_evicted_total metrics.
  • Remove handling of the long-deprecated X-Hasura-Access-Key header. Clients should switch to X-Hasura-Admin-Secret.
  • Add an 'extra_required_claims' option to JWT configuration. This allows the
    user to do more strict validation: when an expected
    issuer and/or audience is configured, make sure that the supplied JWT
    contains such a field. By default validation passes in such a situation.
    Users with self-hosted identity systems should be aware and consider turning on
    this option if they know they don't rely upon the default behavior.

CLI

  • Added a new hasura metadata apply-data-sources command (config v3) that applies only the data sources' connection configuration from the project metadata, without replacing the rest of the metadata. It is an idempotent, non-destructive upsert (existing sources keep their tracked tables; new sources are added empty; sources are never dropped). This allows applying data sources before migrations, so the full metadata can be applied after the database schema exists — avoiding the window where newly-applied metadata exposes schema that pending migrations haven't created yet, and supporting change sets that add a new source together with its migrations.