<!-- Thank you for submitting this PR! :) -->
## Description
More metadata resolving into stages, this time the resolving of boolean
expressions. Functional no-op.
V3_GIT_ORIGIN_REV_ID: 5b74f7cd17f919dc54b82c003b7dd937eb69b65e
<!-- Thank you for submitting this PR! :) -->
## Description
This implements the first part of passing boolean expressions as command
arguments. It adds a `BooleanExpression` arm to `ValueExpression`, and
allows them to be resolved in the context of an ObjectType rather than
an entire model.
This means that if a boolean expression is passed to a command argument
that uses a field that doesn't exist, this happens:
<img width="960" alt="Screenshot 2024-04-05 at 15 54 20"
src="https://github.com/hasura/v3-engine/assets/4729125/cd795bc1-9fda-4cfb-bad3-1e70dd6227a0">
The output of this PR is that we can resolve metadata for boolean
expressions in command arguments, and generate a GraphQL schema for
them, but will throw an error if one is actually used. This will be
resolved in the follow-up PR.
V3_GIT_ORIGIN_REV_ID: 20b8840c313d7ee1f56ebd5becdb28bbe7743350
<!-- Thank you for submitting this PR! :) -->
## Description
As part of moving types and functions into resolve stages, this gets rid
of the root-level `data_connector` module and moves it's types into
`data_connectors` and `data_connector_scalar_types` as appropriate.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: 3109cc17931f0db42c7a4448c6d6194033f700e4
<!-- Thank you for submitting this PR! :) -->
## Description
In order to test things quicker, we'd like to be able to build custom
connector and friends in Nix, and then use the containers when running
tests. First step here is to be able to build Docker containers in Nix,
and add a CI job to ensure it still works.
Then we'll move onto publishing and using these images.
No-op build times:
<img width="336" alt="Screenshot 2024-04-25 at 15 53 56"
src="https://github.com/hasura/v3-engine/assets/4729125/47cbc0c5-6e54-4583-aa01-0528d4a21080">
Functional no-op.
V3_GIT_ORIGIN_REV_ID: 8f9d609e26cdd3b0801e61fd361c241ad504dcdf
<!-- Thank you for submitting this PR! :) -->
## Description
As everything is taking shape we're finding more loose bits and pieces
around, this moves `TypeMappings` and `FieldMappings` into the
`data_connector_type_mappings` stage. Functional no-op.
V3_GIT_ORIGIN_REV_ID: 2357e47b68d361b373f9fa886683ceb1fcff7cc3
<!-- Thank you for submitting this PR! :) -->
## Description
I wondered why some benchmarks were very quick seconds and others very
slow (hours). Turns out I only told half of them that I would prefer
them to be fast. Rectified.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: 40bbcc6829e9a4ea85058f2983136024a9971e3b
<!-- Thank you for submitting this PR! :) -->
## Description
The function changed, the name did not, now it makes no sense. Also it's
friend wasn't even used anymore. Functional no-op.
V3_GIT_ORIGIN_REV_ID: 626316acd06f15d89e504365d21131177a41dada
<!-- Thank you for submitting this PR! :) -->
## Description
Benchmarks are running pretty slowly in Github, let's check it's not an
old library version problem.
---------
Co-authored-by: Samir Talwar <samir.talwar@hasura.io>
V3_GIT_ORIGIN_REV_ID: db1a70c5465cf475fa66d2afc981fd496eccacaa
<!-- Thank you for submitting this PR! :) -->
## Description
Listen, I love copy paste, but even I have my limits. Functional no-op.
V3_GIT_ORIGIN_REV_ID: b917cffdfa9289f3fabc105a0d4581fb64998e44
<!-- Thank you for submitting this PR! :) -->
## Description
This splits calculating permissions for types into it's own discreet
stage, and adds a separate `ObjectTypeWithPermissions` type that is
different from the `ObjectTypeRepresentation` type.
90% of this is changing the types that later stages in metadata resolve
use.
Functional no-op.
---------
Co-authored-by: Samir Talwar <samir.talwar@hasura.io>
V3_GIT_ORIGIN_REV_ID: 304a0b7f047dde65b23a7dbcb7775720cebd928e
<!-- Thank you for submitting this PR! :) -->
## Description
The docs.hasura.io site pulls through these examples for documentation.
We'd like to make them more copy/paste-friendly, so we add these fields
even though they're technically discriminators from parent types.
## Changelog
- Add a changelog entry (in the "Changelog entry" section below) if the
changes in this PR have any user-facing impact. See [changelog
guide](https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide).
- If no changelog is required ignore/remove this section and add a
`no-changelog-required` label to the PR.
### Product
_(Select all products this will be available in)_
- [ ] community-edition
- [ ] cloud
<!-- product : end : DO NOT REMOVE -->
### Type
<!-- See changelog structure:
https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog
-->
_(Select only one. In case of multiple, choose the most appropriate)_
- [ ] highlight
- [ ] enhancement
- [ ] bugfix
- [ ] behaviour-change
- [ ] performance-enhancement
- [ ] security-fix
<!-- type : end : DO NOT REMOVE -->
### Changelog entry
<!--
- Add a user understandable changelog entry
- Include all details needed to understand the change. Try including
links to docs or issues if relevant
- For Highlights start with a H4 heading (#### <entry title>)
- Get the changelog entry reviewed by your team
-->
_Replace with changelog entry_
<!-- changelog-entry : end : DO NOT REMOVE -->
<!-- changelog : end : DO NOT REMOVE -->
V3_GIT_ORIGIN_REV_ID: 9c121367fba187b11801f023208733b1c9ce0337
## Description
This allows the engine to be configured to listen on a specific host.
Mostly useful in testing on macOS, as it can be told to listen on
localhost (`::1`) to avoid firewall notifications.
I have also added doc comments to arguments, which will show up in the
help text when running the engine with `--help`.
## Changelog
- Add a changelog entry (in the "Changelog entry" section below) if the
changes in this PR have any user-facing impact. See [changelog
guide](https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide).
- If no changelog is required ignore/remove this section and add a
`no-changelog-required` label to the PR.
### Product
_(Select all products this will be available in)_
- [x] community-edition
- [ ] cloud
<!-- product : end : DO NOT REMOVE -->
### Type
<!-- See changelog structure:
https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog
-->
_(Select only one. In case of multiple, choose the most appropriate)_
- [ ] highlight
- [x] enhancement
- [ ] bugfix
- [ ] behaviour-change
- [ ] performance-enhancement
- [ ] security-fix
<!-- type : end : DO NOT REMOVE -->
### Changelog entry
<!--
- Add a user understandable changelog entry
- Include all details needed to understand the change. Try including
links to docs or issues if relevant
- For Highlights start with a H4 heading (#### <entry title>)
- Get the changelog entry reviewed by your team
-->
The v3 engine can now be configured to listen on a specific host IP
(e.g. `::1` for localhost). This can be useful when securing the service
or in testing.
<!-- changelog-entry : end : DO NOT REMOVE -->
<!-- changelog : end : DO NOT REMOVE -->
V3_GIT_ORIGIN_REV_ID: ac988ce3c6fcdf4545dcb38d29e1aaf5d2fd7d2e
<!-- Thank you for submitting this PR! :) -->
## Description
Resolving stages should own their types, this moves
`ObjectTypeRepresentation` and friends. Functional no-op.
V3_GIT_ORIGIN_REV_ID: ad1933ed547e72e35e853cae22beadf1de5f0459
<!-- Thank you for submitting this PR! :) -->
## Description
Previously boolean expressions were only used on where clauses for
models. We'd also like to use them for arguments for commands to make
permissions work. This PR splits a boolean expression from it's model.
This has the nice side effect of allowing the same boolean expression
type to used across multiple models, which is a sensible thing to want
to be able to do.
Before this change, using the same boolean expression type on two models
would give you this error:
<img width="783" alt="Screenshot 2024-04-19 at 11 53 23"
src="https://github.com/hasura/v3-engine/assets/4729125/bcc7a4b9-8b6f-4d82-9860-190621c0f5fd">
<!--
Questions to consider answering:
1. What user-facing changes are being made?
2. What are issues related to this PR? (Consider adding `(close
#<issue-no>)` to the PR title)
3. What is the conceptual design behind this PR?
4. How can this PR be tested/verified?
5. Does the PR have limitations?
6. Does the PR introduce breaking changes?
-->
## Changelog
- Add a changelog entry (in the "Changelog entry" section below) if the
changes in this PR have any user-facing impact. See [changelog
guide](https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide).
- If no changelog is required ignore/remove this section and add a
`no-changelog-required` label to the PR.
### Product
_(Select all products this will be available in)_
- [X] community-edition
- [X] cloud
<!-- product : end : DO NOT REMOVE -->
### Type
<!-- See changelog structure:
https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog
-->
_(Select only one. In case of multiple, choose the most appropriate)_
- [ ] highlight
- [X] enhancement
- [ ] bugfix
- [ ] behaviour-change
- [ ] performance-enhancement
- [ ] security-fix
<!-- type : end : DO NOT REMOVE -->
### Changelog entry
<!--
- Add a user understandable changelog entry
- Include all details needed to understand the change. Try including
links to docs or issues if relevant
- For Highlights start with a H4 heading (#### <entry title>)
- Get the changelog entry reviewed by your team
-->
Allow the same `ObjectBooleanExpressionType` to be shared between
multiple models.
<!-- changelog-entry : end : DO NOT REMOVE -->
<!-- changelog : end : DO NOT REMOVE -->
V3_GIT_ORIGIN_REV_ID: 6c9979ddaad50d476c0996d1ece48f0cf1c8e99d
This ensures only Criterion benchmarks get called by `cargo bench`.
Previously, some tests were being loaded too. This is an issue because
if we want to provide command-line arguments to Criterion, it will fail
if we run a non-Criterion benchmark.
We need to specify `harness = false` for each benchmark so that they
don't get wrapped by Cargo, and `bench = false` for everything that
doesn't contain benchmarks but _could_ (i.e. unit and integration
tests). I find Cargo very strange in this regard.
In addition, I fixed the validation benchmark by providing a valid SDL
schema.
V3_GIT_ORIGIN_REV_ID: 338ac5b1411eec7af32923863c5b6f3933c0454b
This shrinks the Docker image size by half.
I have also normalized the two Dockerfiles so they share a cache for
longer.
V3_GIT_ORIGIN_REV_ID: f976725b09ad2c8022a912b15cdcde55ce5a9486
The benchmarks were not working because they couldn't access Git
information. While this is fair, they didn't actually fail, they kept
going, so I have improved the script to fail hard, and fixed the bug by
setting `RELEASE_VERSION` so the build script doesn't bother trying to
read Git.
V3_GIT_ORIGIN_REV_ID: 9573ea32371d7a4d7b99c87017a8d5d77815832c
## Description
This PR adds support for GraphQL variables in test cases. This can be
done by adding variables in `variables.json` file in the same directory
as the `request.gql`, `session_variables.json` files. This file is
optional.
Note that it expects a list of variable sets. Each item in the list
corresponds to a variable for each session in `session_variables.json`.
This is useful to run the same query, but with different variables for
different sessions.
Example `session_variables.json` -
```json
[
{
"x-hasura-role": "admin"
},
{
"x-hasura-role": "user_1"
},
{
"x-hasura-role": "user_2"
}
]
```
Example `variables.json`
```json
[
{
"upper_bound": 4
},
{
"upper_bound": 3
},
{
"upper_bound": 2
}
]
```
PS: this PR only modifies the `test_execution_expectation` function, and
not the `test_execution_expectation_legacy` function.
This PR is required to add some tests for #454
V3_GIT_ORIGIN_REV_ID: 31a6f8adc3521367960986d2bc070271ba3e2d73
<!-- Thank you for submitting this PR! :) -->
## Description
Resolving stages should contain the types they produce, so this moves
`ScalarTypeRepresentation` to the `scalar_types` stage and updates
imports. Functional no-op.
V3_GIT_ORIGIN_REV_ID: 24681009ddbf216d3a57b7cb729d644f687cb0c6
<!-- Thank you for submitting this PR! :) -->
## Description
This PR fixes the bug where passing a null value to a nullable input
field resulted in an error. It also uncomments the test for that.
JIRA: https://hasurahq.atlassian.net/browse/V3ENGINE-97
According to [the graphql
spec](https://spec.graphql.org/October2021/#sec-Null-Value):
>
>
> ```graphql
> {
> field(arg: null)
> field
> }
> ```
> The first has explicitly provided null to the argument “arg”, while
the second has implicitly not provided a value to the argument “arg”.
These two forms may be interpreted differently.
We are also considering the two cases separately, i.e., if something is
absent and nullable vs if something is set to null and is nullable. We
are not manually adding the nullable fields and setting them to null if
not specified explicitly.
## Changelog
- Add a changelog entry (in the "Changelog entry" section below) if the
changes in this PR have any user-facing impact. See [changelog
guide](https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide).
- If no changelog is required ignore/remove this section and add a
`no-changelog-required` label to the PR.
### Product
_(Select all products this will be available in)_
- [x] community-edition
- [x] cloud
<!-- product : end : DO NOT REMOVE -->
### Type
<!-- See changelog structure:
https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog
-->
_(Select only one. In case of multiple, choose the most appropriate)_
- [ ] highlight
- [ ] enhancement
- [x] bugfix
- [ ] behaviour-change
- [ ] performance-enhancement
- [ ] security-fix
<!-- type : end : DO NOT REMOVE -->
### Changelog entry
<!--
- Add a user understandable changelog entry
- Include all details needed to understand the change. Try including
links to docs or issues if relevant
- For Highlights start with a H4 heading (#### <entry title>)
- Get the changelog entry reviewed by your team
-->
allow null for nullable field
<!-- changelog-entry : end : DO NOT REMOVE -->
<!-- changelog : end : DO NOT REMOVE -->
---------
Co-authored-by: Anon Ray <ecthiender@users.noreply.github.com>
V3_GIT_ORIGIN_REV_ID: 4aa181899379905aaca1a71f498b85515180ae1d
As per
[V3ENGINE-112](https://hasurahq.atlassian.net/browse/V3ENGINE-112), we
now require that subgraph names be valid graphql identifiers. This PR
updates the type of an `OpenDdSubgraph` to reflect this.
<!-- Thank you for submitting this PR! :) -->
## Description
<!--
Questions to consider answering:
1. What user-facing changes are being made?
2. What are issues related to this PR? (Consider adding `(close
#<issue-no>)` to the PR title)
3. What is the conceptual design behind this PR?
4. How can this PR be tested/verified?
5. Does the PR have limitations?
6. Does the PR introduce breaking changes?
-->
## Changelog
- Add a changelog entry (in the "Changelog entry" section below) if the
changes in this PR have any user-facing impact. See [changelog
guide](https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide).
- If no changelog is required ignore/remove this section and add a
`no-changelog-required` label to the PR.
### Product
_(Select all products this will be available in)_
- [ ] community-edition
- [ ] cloud
<!-- product : end : DO NOT REMOVE -->
### Type
<!-- See changelog structure:
https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog
-->
_(Select only one. In case of multiple, choose the most appropriate)_
- [ ] highlight
- [ ] enhancement
- [ ] bugfix
- [x] behaviour-change
- [ ] performance-enhancement
- [ ] security-fix
<!-- type : end : DO NOT REMOVE -->
### Changelog entry
<!--
- Add a user understandable changelog entry
- Include all details needed to understand the change. Try including
links to docs or issues if relevant
- For Highlights start with a H4 heading (#### <entry title>)
- Get the changelog entry reviewed by your team
-->
Subgraph names are now required to be valid GraphQL identifiers (that
is, to match `"^[_a-zA-Z][_a-zA-Z0-9]*$"`).
<!-- changelog-entry : end : DO NOT REMOVE -->
<!-- changelog : end : DO NOT REMOVE -->
[V3ENGINE-112]:
https://hasurahq.atlassian.net/browse/V3ENGINE-112?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
Co-authored-by: Tom Harding <tom.harding@hasura.io>
V3_GIT_ORIGIN_REV_ID: 616c77a41490e079f6fb03a919f83d3e61270cc5
This splits out a `debug.Dockerfile` which makes use of out-of-band
caching to speed up builds drastically, at the expense of
reproducibility.
It is used to run tests and auxiliary test services (i.e. the custom
connector).
The new `debug.Dockerfile` marks the Cargo dependency and build caches
as Docker caches, which means they are shared between builds. This is
probably fine for local work and testing. The `Dockerfile` continues to
not use a cache like this, to guarantee that it is not polluted by extra
information, at the expense of build speed.
In addition, we build a `nextest` archive ahead of time to avoid
building tests when attempting to run them.
On my machine, a re-run of `just test` now takes seconds.
I have also sped up the `postgres` container start time by creating a
database called "finished" last, and then waiting for that to show up.
V3_GIT_ORIGIN_REV_ID: 7ef0548361987175b68a0cad44c8f2295110a1fb
<!-- Thank you for submitting this PR! :) -->
## Description
Making the graphs is taking too long, re-adding this advisory
measurement time to them.
V3_GIT_ORIGIN_REV_ID: e45ef4b8b8c8fd0cf45aacb989dd2e382b6b958a
<!-- Thank you for submitting this PR! :) -->
## Description
Had two types that were identical except for their `scalars` field. Have
extracted the commonality to make this easier to change in future.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: 4ab5582e8ca62fc85345c6273cab3b0c4741b38b
I was on a roll.
I also replaced `futures` with `futures-util`, which is theoretically
smaller.
V3_GIT_ORIGIN_REV_ID: 27228a506f1edb6d0e33a4c61499e500cc5d0df7
This changes the way we build the custom connector so that the data is
baked in at compile time, not loaded from the file system at runtime.
This simplifies packaging.
I also took the liberty to switch out `.unwrap()` for `anyhow`, and to
avoid parsing a string to construct the socket address.
V3_GIT_ORIGIN_REV_ID: d562e0a9852b4e3ecde45bd6938d8eb1b066211b
## Description
We set W3C and B3 trace headers when making JWT authentication HTTP
requests to obtain JWKs. This will allow us to figure out what's going
on if we spend a lot of time here.
## Changelog
- Add a changelog entry (in the "Changelog entry" section below) if the
changes in this PR have any user-facing impact. See [changelog
guide](https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide).
- If no changelog is required ignore/remove this section and add a
`no-changelog-required` label to the PR.
### Product
_(Select all products this will be available in)_
- [ ] community-edition
- [x] cloud
<!-- product : end : DO NOT REMOVE -->
### Type
<!-- See changelog structure:
https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog
-->
_(Select only one. In case of multiple, choose the most appropriate)_
- [ ] highlight
- [x] enhancement
- [ ] bugfix
- [ ] behaviour-change
- [ ] performance-enhancement
- [ ] security-fix
<!-- type : end : DO NOT REMOVE -->
### Changelog entry
<!--
- Add a user understandable changelog entry
- Include all details needed to understand the change. Try including
links to docs or issues if relevant
- For Highlights start with a H4 heading (#### <entry title>)
- Get the changelog entry reviewed by your team
-->
- JWT authentication requests over HTTP now propagate trace headers when
making request for JWKs. These can be used to identify latency in
authentication.
<!-- changelog-entry : end : DO NOT REMOVE -->
<!-- changelog : end : DO NOT REMOVE -->
V3_GIT_ORIGIN_REV_ID: 70fa68c85eb4ffcc76e445771263ce08496dc4b4
When trying to reduce the number of dependencies we use in the engine, I
was blocked by a few `.clone()` calls that, on inspection, turned out to
be completely unnecessary.
I have replaced those with passing by reference, and then gone on a
pedant spree. I enabled the `needless_pass_by_value` Clippy warning and
fixed it everywhere that it highlighted. In most places, this meant
adding `&`, but I also marked some types as `Copy`, which makes
pass-by-value the right move.
In one place, I replaced calls to `async_map` with `if` and `else`, to
avoid constructing closures that capture across async boundaries. This
means I could just delete `async_map`.
V3_GIT_ORIGIN_REV_ID: 6ff71f0c553b707889d89552eff3e8c001e898cc
<!-- Thank you for submitting this PR! :) -->
## Description
Following https://github.com/hasura/v3-engine/pull/470 , split data
connector scalar type representations resolve step into a separate stage
and files etc. Functional no-op.
V3_GIT_ORIGIN_REV_ID: 3bcef6b58c0a4f4f7fa529456cb4261667a7e0ce
<!-- Thank you for submitting this PR! :) -->
## Description
Following from https://github.com/hasura/v3-engine/pull/469 , we split
scalar type resolution too. That will need to be merged before this so
we can tidy up the data passing between them.
No functional change.
V3_GIT_ORIGIN_REV_ID: 5e157c4d15d0223d2bbd24f911ebee24e98b81cd
<!-- Thank you for submitting this PR! :) -->
## Description
Fairly mechanical change to split the data connector type mappings
resolve into own folders / stage. No functional changes.
V3_GIT_ORIGIN_REV_ID: 805c9d056a64a47afa9005674298e7417e58dad7
This uses the `json!` macro in the JWT client code and its associated
tests, rather than embedding a string and parsing it. This will make
compilation fail if the JSON is invalid, which seems better than a
runtime/test-time failure.
There are a few cases where we were constructing a JSON string by
concatenating strings using `format!`. `json!` also handles these cases
better, as you can refer to a JSON value by its variable name too, and
it doesn't require escaping `{` and `}`.
V3_GIT_ORIGIN_REV_ID: 4c40299b71d583efae7b0cdbabee8cff21b09bef
## Description
There are no user-facing changes in this PR. It just adds the
`Deserialize` trait to `AuthConfig` and makes some changes to internal
functions to avoid clones.
---------
Co-authored-by: Samir Talwar <samir.talwar@hasura.io>
V3_GIT_ORIGIN_REV_ID: 2e8956bdd3827715693eb14239c808baf737d588
Previously, negative values for `offset` and `limit` input fields
resulted in an internal error and not exposed in the API response. The
reason is that these errors are raised from normalized_ast conversion
after GraphQL validation. The validation will only check for the type,
but not the value of the input fields.
This Commit:
- Introduces a utility function to lift any unexpected value internal
error to external.
- Use the function for `limit` and `offset` input field value coercion.
V3_GIT_ORIGIN_REV_ID: a186eb89a836359427e58f7a847eab3e2f8fafa4
<!-- Thank you for submitting this PR! :) -->
## Description
In https://github.com/hasura/v3-engine/pull/441 we made all our skipped
Clippy rules explicit. This enables one (pretty arbitrarily) and fixes
what comes up.
V3_GIT_ORIGIN_REV_ID: 406692a2a134cb2a6cf5785acd0ac7c5b9f90c61
## Description
This modifies handling of the NDC response so we deserialize it once,
not twice.
The previous code deserialized first to `serde_json::Value`, and then
again to the required type. This is costly and unnecessary. By
parameterizing over the type, we can go directly to the type we're
looking for.
We still want to do the two-step process for errors, but it's probably
fine if they remain a little slower as the error response shouldn't be
too large.
Analysis with flamegraphs before and after shows a dramatic drop in CPU
time as a result.
V3_GIT_ORIGIN_REV_ID: d7574bd8c82f0863372e1463fda020a8174c7341
