<!-- Thank you for submitting this PR! :) -->
## Description
Now that metadata resolve has a clear interface with the rest of the
engine, let's take it out into it's own crate. This will make it easier
to maintain a strong boundary between things.
To simplify imports etc, removed nested layers of modules, so now we
import `use metadata_resolve::Qualified` instead of `use
crate::metadata::resolved::Qualified`.
The changes in `engine` crate are all just updating imports.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: fb94304f7ed8883287c18bd6870045dfd69e3fe3
<!-- Thank you for submitting this PR! :) -->
## Description
We'd like to split metadata resolve into it's own crate to enforce
module boundaries better. In doing so, discovered that it's using a type
from the later schema stage called `PredicateRelationshipAnnotation`,
which isn't really an annotation type at all, just a data structure for
a resolved predicate.
This moves that types back into metadata resolve, renaming it to
`PredicateRelationshipInfo`.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: 5b37ca77fb4ddf17093277e6727360d6077c4e06
The massive `Error` enum from `execute.rs` disintegrates into the
following independent error types.
- `RequestError`: All exceptions occurred before executing the root
field plans. Each variant in this error enum contains the error type
stemming from isolated steps in the pipeline involving parsing,
validation, IR conversion, and plan generation.
- `FieldError`: Exception occurred when resolving a field through its
plan. Multiple root fields are executed isolated, and field errors are
collected in a list.
Code paths for `explain` and `execute` query are split into two
functions. This is done to avoid few error variants and unburden the
function that previously does both.
V3_GIT_ORIGIN_REV_ID: 21f2f43ee4805a955fa0ce7d9b45c4b1902def63
<!-- Thank you for submitting this PR! :) -->
## Description
We named this stage after the least interesting thing about it, this
resolves that.
`data_connector_type_mappings` -> `object_types`.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: 67c94356cc7207e94eb3b696abbd32efe31551ac
<!-- Thank you for submitting this PR! :) -->
## Description
`data_connector_type_mappings` is a map of data connector information
keyed by `CustomTypeName`. We create it when we resolve object types,
which are also keyed by `CustomTypeName`, however we pass them around
separately and it's not immediately obvious that they are related.
This PR stops passing `data_connector_type_mappings` around and instead
includes them with the object information.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: 3ac1341907ea88c11fbc3639adf63140aa702262
## Description
1. I've moved the architecture information we had in `CONTRIBUTING.md`
to a separate document `docs/architecture.md` so we can evolve both
separately in the future.
2. I've introduced a couple of sub directories: `utils` and `auth`, for
supporting crates that are not the core functionality of the engine so
it is easier to find the most relevant crates.
New structure:
```
crates
├── auth
│ ├── dev-auth-webhook
│ ├── hasura-authn-core
│ ├── hasura-authn-jwt
│ └── hasura-authn-webhook
├── custom-connector
├── engine
├── lang-graphql
├── metadata-schema-generator
├── open-dds
└── utils
├── opendds-derive
├── recursion_limit_macro
└── tracing-util
```
V3_GIT_ORIGIN_REV_ID: e0e9394da2fcd911f329c48107a76f8492fa304c
## Description
To clarify the purpose of the `"source"` field, we've decided to rename
it to `"sourceType"`. This hopefully makes it clearer that the value
should be a type name.
`"source"` is still accepted as an alias in order to stop this from
being a breaking change.
I have added the aliasing capability for struct fields in
`opendds_derive`.
All test metadata has been updated to use `"sourceType"`, but I've added
one test case that uses `"source"` instead just to make sure that it
still works.
## 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
- [ ] 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
-->
- OpenDDS: The `"source"` field for relationships has been renamed to
`"sourceType"`. Metadata using `"source"` will continue to work as
usual, but new metadata should be authored with `"sourceType"` instead.
<!-- changelog-entry : end : DO NOT REMOVE -->
<!-- changelog : end : DO NOT REMOVE -->
V3_GIT_ORIGIN_REV_ID: 305cbf7a62ee49a715e95ad892b8d00647f05cef
I found myself wanting to rewrite JSON files with `sed`. The problem is,
then I want to run a formatter over them afterwards, and this will
change the whole file, not just the area I touched.
I would like to propose the nuclear option in remedying this: format
everything now. This is a very large change that should make it easier
to keep files to a consistent format in the future.
I have chosen to use Prettier for this because (a) it has a useful
`--write` command and (b) it also does GraphQL, Markdown, YAML, etc.
I've elected to exclude two sets of files:
1. `crates/custom-connector/data/*.json`, because they are actually
multiple JSON objects, one per line, which Prettier cannot parse.
2. `crates/lang-graphql/tests/**/*.graphql`, because it contains invalid
GraphQL, and the parser is intended to work with strangely-formatted
GraphQL.
The main changes are standardizing whitespace, adding a newline at the
end of files, and putting JSON arrays on one line when they fit.
V3_GIT_ORIGIN_REV_ID: 92d4a535c34a3cc00721e8ddc6f17c5717e8ff76
By wrapping the errors we can work with both `syn` and `darling` errors,
allowing us to avoid `.unwrap` and `.expect`. This makes failures way
more useful.
V3_GIT_ORIGIN_REV_ID: bd7c4a4e7de4a2360b4533d9238199f098a09a8d
<!-- Thank you for submitting this PR! :) -->
## Description
This stacks on top of https://github.com/hasura/v3-engine/pull/526 and
is the tidying up step following it.
There is a lot going on here, none of it particularly interesting.
- We remove the old `resolve_metadata` function, so all of "the action"
for resolving metadata happens inside `resolved::stages::mod`.
- We move the remaining modules into two folders, `helpers` and `types`.
This is a pretty rough cut, and there are definitely better homes for
the things here, I just wanted the separation of stages and "other bits"
to be clearer.
- We split the `types` helpers into `types` and `type_mappings`, as the
`type_mappings` stuff was clearly defined and didn't belong with the
grab-bag of functions that remain in `types`.
- We explicitly export everything used outside metadata resolve, and
stop other modules dipping into it's internal structure. This will make
future changes (particularly refactors that change the stages etc) a lot
easier as we don't need the rest of the app concerning itself with it.
- I _think_ we may now be able to move metadata resolve into a separate
crate. I have not tried yet, this PR is already silly enough.
When given a choice between "fixing" something, and doing the most
mechanical obvious change, I have opted for the latter. That is to
derisk this big change, and to ensure it doesn't linger, collecting
awful merge conflicts.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: 2b52403cbfddb0427b8a3e61ad2edaef9d1b3b46
<!-- Thank you for submitting this PR! :) -->
## Description
Following work in https://github.com/hasura/v3-engine/pull/523 and
friends, this resolves `model_permissions` in a fresh step, creating a
new `ModelWithPermissions` type to differentiate from the regular
`Model` which no longer has any notion of permissions.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: fdf928ae12159a6c4ef87effc4704193c5306e46
<!-- Thank you for submitting this PR! :) -->
## Description
Follow up to https://github.com/hasura/v3-engine/pull/523
This removes the `Option` from the Command permissions. Seperated from
the pure "moving things around" PR for clarity, it should be a
functional no-op though, as Command permissions are opt-in, so `None`
and `Some(HashMap::new())` are equivalent, and this layer can be
removed.
V3_GIT_ORIGIN_REV_ID: ebd8fbb54c0f771b7128ff499af2abea85f73808
<!-- Thank you for submitting this PR! :) -->
## Description
Following https://github.com/hasura/v3-engine/pull/522 and friends, this
breaks out the command permissions into a discreet metadata step. This
creates a new `CommandWithPermissions` with type which is available
after this step, and removes the `Option<CommandPermission>` from the
regular `Command` type.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: ac076a93257d25ec5f9367a5a0b280f8b63371fc
<!-- Thank you for submitting this PR! :) -->
## Description
This separates out the stage that resolves relationships. The most
important thing here is that we no longer have a `relationships` field
in `ObjectTypeRepresentation` that may or may not be populated, and
instead add a new wrapper type `ObjectTypeWithRelationships`, which is
used downstream of this stage.
Stacked on top of https://github.com/hasura/v3-engine/pull/521
Functional no-op.
V3_GIT_ORIGIN_REV_ID: 1e6ca41e55b8cc470385c35bbd7999fa7a2bce6e
<!-- Thank you for submitting this PR! :) -->
## Description
Following https://github.com/hasura/v3-engine/pull/520, there are a
couple of loose things that occur in the big metadata resolve, given
them their own stages too. Functional no-op.
V3_GIT_ORIGIN_REV_ID: 2b7454ce997411da7dd9551ac05a4180b137e0a0
<!-- Thank you for submitting this PR! :) -->
## Description
Following https://github.com/hasura/v3-engine/pull/519 here is the
equivalent change for `commands` which are fortunately, much simpler.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: 24ec7107018ed29e251452c9ca19c5b0538cd0c6
<!-- Thank you for submitting this PR! :) -->
## Description
As per https://github.com/hasura/v3-engine/pull/483 and all PRs
proceeding it, this moves the resolving of Models into a discreet
metadata stage. The `resolve::model` module was a bit of a dumping
ground, so I have tried to find more sensible homes for a lot of things,
but some things remain (model permissions) and will be homed when
sorting later stages.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: b41bcc9f413a867f21dd72b5d7affee8d55e02df
<!-- 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
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
## 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
