* formats kodiak commit message in PR description
* include co-author information while merging
GitOrigin-RevId: 339be665391326a9c33f76f187dcaa242df5f8a1
* Remove unused ExitCode constructors
* Simplify shutdown logic
* Update server/src-lib/Hasura/App.hs
Co-authored-by: Brandon Simmons <brandon@hasura.io>
* WIP: fix zombie thread issue
* Use forkCodensity for the schema sync thread
* Use forkCodensity for the oauthTokenUpdateWorker
* Use forkCodensity for the schema update processor thread
* Add deprecation notice
* Logger threads use Codensity
* Add the MonadFix instance for Codensity to get log-sender thread logs
* Move outIdleGC out to the top level, WIP
* Update forkImmortal fuction for more logging info
* add back the idle GC to Pro
* setupAuth
* use ImmortalThreadLog
* Fix tests
* Add another finally block
* loud warnings
* Change log level
* hlint
* Finalize the logger in the correct place
* Add ManagedT
* Update server/src-lib/Hasura/Server/Auth.hs
Co-authored-by: Brandon Simmons <brandon@hasura.io>
* Comments etc.
Co-authored-by: Brandon Simmons <brandon@hasura.io>
Co-authored-by: Naveen Naidu <naveennaidu479@gmail.com>
GitOrigin-RevId: 156065c5c3ace0e13d1997daef6921cc2e9f641c
Generalize TableCoreInfoRM, TableCoreCacheRT, some table metadata data types, generalize fromPGCol to fromCol, generalize some schema cache functions, prepare some enum schema cache code for generalization
GitOrigin-RevId: a65112bc1688e00fd707d27af087cb2585961da2
An incremental PR towards https://github.com/hasura/graphql-engine/pull/5797
- Expands `MonadMetadataStorage` with operations related to async actions and setting/updating metadata
GitOrigin-RevId: 53386b7b2d007e162050b826d0708897f0b4c8f6
Since PDV, introspection queries are parsed by a certain kind of reflection where during the GraphQL schema generation, we collect all GraphQL types used during schema generation to generate answers to introspection queries. This has a great advantage, namely that we don't need to keep track of which types are being used in our schema, as this information is extracted after the fact.
But what happens when we encounter two types with the same name in the GraphQL schema? Well, they better be the same, otherwise we likely made a programming error. So what do we do when we *do* encounter a conflict? So far, we've been throwing a rather generic error message, namely `found conflicting definitions for <typename> when collecting types from the schema`. It does not specify what the conflict is, or how it arose. In fact, I'm a little bit hesitant to output more information about what the conflict is, because we support many different kinds of GraphQL types, and these can have disagreements in many different ways. It'd be a bit tiring (not to mention error-prone) to spell this out explicitly for all types. And, in any case, at the moment our equality checks for types is incorrect anyway, as we are avoiding implementing a certain recursive equality checking algorithm.
As it turns out, type conflicts arise not just due to programming errors, but also arise naturally under certain configurations. @codingkarthik encountered an interesting case recently where adding a specific remote and a single unrelated database table would result in a conflict in our Relay schema. It was not readily visible how this conflict arose: this took significant engineering effort.
This adds stack traces to type collection, so that we can inform the user where the type conflict is taking place. The origin of the above conflict can easily be spotted using this PR. Here's a sample error message:
```
Found conflicting definitions for "PageInfo". The definition at "mutation_root.UpdateUser.favourites.anime.edges.node.characters.pageInfo" differs from the the definition at "query_root.test_connection.pageInfo"
```
Co-authored-by: Antoine Leblanc <antoine@hasura.io>
GitOrigin-RevId: d4c01c243022d8570b3c057b168a61c3033244ff
* Add update_by_pk test with more interesting permissions.
* Add new delete test with more interesting permissions.
* Fix byPk operations not providing all columns.
* Empty commit to unlock ci.
GitOrigin-RevId: eb1ca2cc4c59f421bc5fedf49bef91aa4bbdca94
This PR makes a bunch of schema generation code in Hasura.GraphQL.Schema backend-agnostic, by moving the backend-specific parts into a new BackendSchema type class. This way, the schema generation code can be reused for other backends, simply by implementing new instances of the BackendSchema type class.
This work is now in a state where the schema generators are sufficiently generic to accept the implementation of a new backend. That means that we can start exposing MS SQL schema. Execution is not implemented yet, of course.
The branch currently does not support computed fields or Relay. This is, in a sense, intentional: computed field support is normally baked into the schema generation (through the fieldSelection schema generator), and so this branch shows a programming technique that allows us to expose certain GraphQL schema depending on backend support. We can write support for computed fields and Relay at a later stage.
Co-authored-by: Antoine Leblanc <antoine@hasura.io>
GitOrigin-RevId: df369fc3d189cbda1b931d31678e9450a6601314
* init oss ci tests in monorepo
* uses circle env to set base branch
* change ref name to filter_only_vtags
* install from local artifact
* updates comment in ciignore script
* adds oss_all_server_tests_pass job
Co-authored-by: scriptonist <aravindkp@hasura.io>
GitOrigin-RevId: 681b73c7c8331950d84fdd86111ab4297bb60725
