In preparation for tightening up the various ways in which we construct and work with session variables, I am trying to move the behavior into the same module(s) as the data types, so that we can avoid exposing the internals of data structures in favor of smart constructors and conversions.
The session variable code was split between `Hasura.RQL.Types.Roles`, `Hasura.RQL.Types.Session`, and `Hasura.Session`, with the first two containing most of the data structures (and some logic) and the latter containing the rest of the logic. These files do not interact with the rest of `Hasura.RQL`, though they are depended upon by that namespace.
I have refactored these files into a new namespace, `Hasura.Authentication`. It now looks like this:
1. Role types are now in `Hasura.Authentication.Role`.
2. Header constants were moved from `Hasura.Server.Utils` to `Hasura.Authentication.Headers` (plural) to avoid cycles.
3. Header logic was moved from various places into `Hasura.Authentication.Header` (singular) for the same reason.
4. Session variable types and logic live together in `Hasura.Authentication.Session`.
5. User info types and logic live together in `Hasura.Authentication.User`.
This new structure is cycle-free and generally avoids importing the rest of the code, which means we should be able to start pruning the list of exports and locking down session variable construction.
No behavior was changed in this changeset.
The majority of changes are to the imports in a number of files; everything depends on these things. By splitting into multiple files, we also reduce the surface area of an individual import, which was a pleasant side-effect of this work.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/10960
GitOrigin-RevId: 7cb962c06483cd9b92b80432aed5cabecb465cda
…arger ones
…the goal being to save on data transfer costs, libdeflate being much faster than zlib for larger inputs and at higher compression levels. A few notes:
In last month...
- 95% of response bodies > 20kB compress below 32% (with zlib level 1)
- The 10% of responses > 20kB comprise 75% egress traffic to clients
- libdeflate at level 6 is comparable in performance to zlib level 1, and twice as fast as zlib level 6
- We expect compressing 20kB+ response bodies at level 6 to reduce data transfer to clients by 25% or so (although this is difficult to predict accurately)
The new libdeflate bindings used here also need review: https://github.com/hasura/libdeflate-hs
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/10341
GitOrigin-RevId: bc7b19e0024e442d85ac0b34995610edbab13bd6
This turns on the `partial-fields` warning, which yells at you if you try and create fields on sum types that end up being partial functions. These are dangerous; we had a bug because we introduced a new case to a data type, making the field accessors partial, and leading to a crash in certain cases.
This means that we have introduced a few wrappers in various places where the field names are useful, but we want to avoid partial matches.
Unfortunately this can be turned off by prefixing the field name with an underscore. Ideally we would try and avoid exporting any field names with underscores, but lenses make this hard. I have removed some underscores for the areas in which we've seen this break in the past.
We will have to be vigilant.
[NDAT-794]: https://hasurahq.atlassian.net/browse/NDAT-794?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/9991
GitOrigin-RevId: fd69b1ef999682969f3507f0e97513f983da4da6
A fix for #9447
Before this change, for the workload in the ticket, we saw a memory stay at around 4 GB an hour after the workload ended. after this change we see both a lower memory high watermark, and also see memory come back to baseline at the end as we expect (after the `HASURA_GRAPHQL_PG_CONN_LIFETIME` and a subsequent `_idleStaleReaperThread` interval elapses). But note the numbers given on any given machine may be slightly different, since the behavior depends on the version of glibc and processor speed (Since the test case depends on the server being overloaded).
This might also help some users commenting in https://github.com/hasura/graphql-engine/issues/9592
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/9823
GitOrigin-RevId: 5650aa42d10d46c418c21686983a982d69011884
There is already a library in Hackage called "error-message".
This breaks the Nix build as we end up overriding that library, which causes a change to any of its dependents.
Outside Nix, Shadowing isn't strictly a problem, but it's prudent to avoid it in case we accidentally end up with the other library in edge cases.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/9679
GitOrigin-RevId: e3f54fd4e5eafec9b0a00128767daad0c8aeab72
