In certain circumstances, all HTTP headers were included in the set of session variables. This has now been reduced to only the session variables. This change affects a number of areas, including the HTTP logs, JWT claims, rate limiting, and accessing session variables in Kriti code.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/10964
GitOrigin-RevId: fc573cd89f7c0f1a17b9e8a56396f31e70669650
Alpine is often slower than Debian (because musl is sometimes slower than glibc) and not how anyone actually deploys PostgreSQL in production.
Most notably, some floating-point computations result in slightly different values, and Debian ships with better support for different locales so sorting text (e.g. with `ORDER BY`) behaves differently.
Let's test against an environment that people are likely to actually use.
As a result, there are slight changes to the results of PostGIS computations in a couple of test cases.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/10942
GitOrigin-RevId: 4caed19def23a372fc3930c409514b1c9b385026
Redis-based caching: the endpoints related to clearing the cache and gathering cache metrics would sometimes miss keys. This has been remedied.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/10843
GitOrigin-RevId: 4fafb17fc570b3dc2e265493f967f8b30eace46a
This fixes the existing tests around query caching and other Redis-related behaviors so they actually run.
Some of the tests still fail because of a couple of bugs, but the error messages are now meaningful.
They do not yet run in CI. We will enable them once they are fixed.
I added a bit of extra logging; we now log the Redis server host and port. I also left in the `Show` instance derivations I used for debugging, as I don't think they'll harm anything and might be useful in the future.
The changes are as follows:
1. I added a `redis` server to the tests and configured both HGE and the test runner to talk to it.
2. I fixed up the action tests so they set up and tear down correctly, including a fix to the output type of the action.
3. Caching has been implemented for actions with client header forwarding, so I have changed the test accordingly.
4. Tests now fail correctly if the response headers are wrong but the body is correct.
5. I have updated the keys in the response headers as the algorithm for generating them seems to have changed.
6. A few improvements have been made to the Python tests to handle lint warnings and improve logging.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/10839
GitOrigin-RevId: 5d31a376346190b5c7b398b4dee84b88a9d1b18b
This changes our test configuration to use the PostgreSQL 16 image from `postgis/postgis`.
In addition, it bumps PostGIS to v3.4 (from v3.3).
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/10361
GitOrigin-RevId: 883c96d8453efb42b226f849891488382a99c80c
Now that Docker for macOS supports using Rosetta for x86/amd64 emulation, we no longer need to use the `azure-sql-edge` image. We can always use the official `mcr.microsoft.com/mssql/server` one.
This also means that we no longer need the separate healthcheck container, because the official image ships with `sqlcmd`.
When this is merged, you will need to ensure you have enabled Rosetta emulation in the Docker settings to test against SQL Server on macOS. This requires macOS 13 (Ventura).
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/10139
GitOrigin-RevId: 2225bf5f4c6d3632da1f29b2229c9b04ead5e34c
Upgrade to GHC 9.4.5, and update any tests.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8954
Co-authored-by: Mohd Bilal <24944223+m-Bilal@users.noreply.github.com>
Co-authored-by: Samir Talwar <47582+SamirTalwar@users.noreply.github.com>
Co-authored-by: Philip Lykke Carlsen <358550+plcplc@users.noreply.github.com>
GitOrigin-RevId: 5261126777cb478567ea471c4bf5441bc345ea0d
When upgrading to GHC v9.4, we noticed a number of failures because the sort order of HashMaps has changed. With this changeset, I am endeavoring to mitigate this now and in the future.
This makes one of two changes in a few areas where we depend on the sort order of elements in a `HashMap`:
1. the ordering of the request is preserved with `InsOrdHashMap`, or
2. we sort the data after retrieving it.
Fortunately, we do not do this anywhere where we _must_ preserve order; it's "just" descriptions, error messages, and OpenAPI metadata. The main problem is that tests are likely to fail each time we upgrade GHC (or whatever is providing the hash seed).
[NDAT-705]: https://hasurahq.atlassian.net/browse/NDAT-705?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/9390
GitOrigin-RevId: 84503e029b44094edbbc298651744bc2843c15f3
We seem to be getting flakes where we try and use the same port for two different servers. This is because in certain cases we cannot simply allocate the port dynamically, but have to decide it in advance, leading to a race condition.
We resolve this by keeping track of the ports we allocate when using this method, making sure we never allocate them twice. We also make sure we allocate from a different pool of ports to the usual dynamic port pool (typically above port 32768, and often above port 49152).
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8903
GitOrigin-RevId: 375a23867591a4566493dddbc550c58cf88ea392
I'm hoping this will reduce the flakiness of the tests, by ensuring the servers stop appropriately.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8880
GitOrigin-RevId: 6379b18cbe43527a1c2e73a14d93179b54bf1b75
These tests are intended to catch issues in upgrading HGE. However:
* the tests are very convoluted and hard to understand,
* we can only run a small subset of Python tests that don't mutate any data or metadata, and
* I have never seen them fail for a legitimate reason, but I've seen a lot of flakes.
While we do believe it's important to test that upgrades don't break the stored introspection, these tests don't seem to be doing that any more. I humbly request that we delete them now and either (a) figure out how to test this properly, or (b) just wait for v3, which does away with reintrospecting on server startup entirely.
[NDAT-259]: https://hasurahq.atlassian.net/browse/NDAT-259?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8844
GitOrigin-RevId: 528bc632fce377b7eff2026b832bd58586ac5a0b
This rewrites the JWT tests to generate and specify the secrets per test class, and to provide the server configuration to the HGE fixture.
It covers the tests in:
- *test_jwt.py*
- *test_jwt_claims_map.py*
- *test_config_api.py*
- *test_graphql_queries.py* (just a couple here)
This does reduce the number of code paths exercised with JWT, as we were previously running *all* tests with JWT tokens. However, this seems excessive; we don't need to tread every code path, just enough to ensure we handle the tokens appropriately. I believe that the test coverage in *test_jwt.py* does this well enough (though I'd prefer if we moved the coverage lower down in the stack as unit tests).
These tests were configured in multiple different ways by *test-server.sh*; this configuration is now moved to test subclasses within the various files. This results in a bit of duplication.
Unfortunately, the tests would ideally use parameterization rather than subclassing, but that doesn't work because of `hge_fixture_env`, which creates a "soft" dependency between the environment variables and `hge_server`. Parameterizing the former *should* force the latter to be recreated for each new set of environment variables, but `hge_server` isn't actually aware there's a dependency.
It currently looks like this adds lines of code; we'll more than make up for it when we delete the relevant lines from *test-server.sh*. I am not doing that here because I plan on deleting the whole file in a subsequent changeset.
[NDAT-538]: https://hasurahq.atlassian.net/browse/NDAT-538?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8803
GitOrigin-RevId: f7f2caa62de0b0a45e42964b69a8ae73d1575fe8
This adds the ability to capture logs to the HGE fixture, and uses this in test_logging.py to analyze the logs, instead of relying on a shell script redirecting the logs to a file.
We then inject the logs into the tests and parse the JSON. Because we're no longer reading a file, we need to do this in a separate thread, as we'll block on reading rather than the stream ending. (Once HGE stops, the stream will be closed.)
Some of the tests require a JWK server, so this has been extracted from test_jwk.py.
[NDAT-540]: https://hasurahq.atlassian.net/browse/NDAT-540?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8772
GitOrigin-RevId: 9413e714f1c42b8a0991d0d30c4358209fd30c0c
This requires rewriting the test class to split it into 3, each specifying the correct environment variables for HGE.
It would be lovely to use parameterization rather than subclassing, but that doesn't work because of `hge_fixture_env`, which creates a "soft" dependency between the environment variables and `hge_server`. Parameterizing the former *should* force the latter to be recreated for each new set of environment variables, but `hge_server` isn't actually aware there's a dependency. See `TestParameterizedFixtures` in test_tests.py for more information.
[NDAT-539]: https://hasurahq.atlassian.net/browse/NDAT-539?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8747
GitOrigin-RevId: 878b2fc20f39f962a67cd950046a99c283cfc6fc
