This keeps versions in one place so we can more easily ensure we upgrade
crates together.
V3_GIT_ORIGIN_REV_ID: 6a929bb6196c19a1f66a768585b669127035e9be
Return a `T` instead of a `Result<T, E>` when we never return an error
(`E`) case.
I also enabled some more warnings. `unnecessary_box_returns` has been
suppressed where appropriate, and `unused_async` doesn't seem to be
violated anywhere any more.
I got rid of some calls to `.unwrap()` too.
V3_GIT_ORIGIN_REV_ID: 015ebd05978cf8c2d87474a90e0cd4333779a761
We pretend we handle directives but we simply set them to an empty map,
and then don't actually use them at all.
This is completely unused code that can be removed.
V3_GIT_ORIGIN_REV_ID: a86dc43acc2de2f2d3f78f0c8ebc53ce9f5bde8c
<!-- Thank you for submitting this PR! :) -->
## Description
It turns out that every usage of `Builder::allow_all_namespaced`
concerned itself with either introspection nodes or (in the GDS case)
`None`.
Combined with the fact that both the SDL and GDS implementations of
`SchemaContext::introspection_namespace_node` were trivial, the
`NamespacedNodeInfo` contained in
`Namespaced::AllowAll(S::NamespacedNodeInfo)` is always functionally
meaningless.
This PR removes the `NamespacedNodeInfo` from `Namespaced::AllowAll` as
well as `SchemaContext::introspection_namespace_node`, thus simplifying
the implementation.
<!--
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
- [ ] 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: 1525905488203ff07182aa700c9fff26512743ab
If a function doesn't return a value, terminate with a semicolon.
I also moved `implicit_hasher` and `return_self_not_must_use` to the
"definitely keep disabling this" list, and installed
[Bacon](https://dystroy.org/bacon/) in the Nix shell to make it easier
to run Clippy.
V3_GIT_ORIGIN_REV_ID: ffb17b42d982518aec433a1676dba0a0dd0ad95d
<!-- Thank you for submitting this PR! :) -->
## Description
With the introduction of `NamespacedGetter` as the means deciding how to
interpret what it means to extract "namespaced" data from a schema it is
superfluous to thread along the "namespace" that lookups will be based
on.
This PR removes those namespace arguments.
As a nice side effect this removes the cases where we used to have to
supply a dummy role value when generating a role-agnostic schema.
<!--
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
- [ ] 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: 0aca2b3838f1b0d944b3c41ddd54d20dc74503a4
<!-- Thank you for submitting this PR! :) -->
## Description
This PR is a refactoring which is a functional no-op.
<!--
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
- [ ] 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: 625475ef23ef7fd2f72921e951fa1a957807516a
1. Use `map_or(…, …)` instead of `.map(…).unwrap_or(…)`.
2. Use `.is_some_and(…)` instead of `.map(…).unwrap_or_default(…)`.
3. Nest `|` patterns where possible.
4. Be more specific about match patterns.
I found I could also simplify `typecheck_qualified_type_reference`
considerably.
V3_GIT_ORIGIN_REV_ID: 6a3b1a4c525c0187c2fdb6df0c979ca0b7b3016c
This PR refactors the schema crate to enable overriding the
interpretation of roles at runtime.
By providing a `NamespacedGetter` that ignores roles entirely (i.e.
`GDSNamespacedGetterAgnostic`) to schema generation functions it is
possible to derive a GraphQL schema that ignores permissions and
presets.
This PR leaves back a few opportunities to improve code clarity, which I
hope to address in follow-up PRs.
For instance, it seems superfluous to make sense for generic code
parametrised `<S: SchemaContext>` to carry around both a `S::Namespace`
and a `S::NamespaceGetter`, when all that code could ever do with that
`S::Namespace` value anyway is apply it to the `S::NamespaceGetter`.
Taking this line of reasoning to its conclusion suggests that we can
reduce the complexity of `trait SchemaContext` and its associated types
and kit.
---------
Co-authored-by: Samir Talwar <samir.talwar@hasura.io>
V3_GIT_ORIGIN_REV_ID: c84555fd88279582670919faa5a62bbd00b714bd
Rather than allowing the `cast_precision_loss` and `inline_always`
warnings everywhere, we just suppress them in the few places they're
already used.
V3_GIT_ORIGIN_REV_ID: c28350a21efa029c8c6aae2a602eec2d75f42216
Add the ability to render field input-arguments and default values in
sdl.
Also add a small CLI tool to help inspect the GraphQL schemas that
result from a piece of engine metadata.
V3_GIT_ORIGIN_REV_ID: ddb7315f12d24eafbf57782f37f840ca44d94789
Just because it's fewer lines of code.
1. Invert `if`/`else` blocks with negative conditions.
2. Unwrap redundant `else` blocks.
3. Simplify a few branches to `let … else`.
4. Replace a `match` with `if let`.
V3_GIT_ORIGIN_REV_ID: 4f10730b688d21c1fc86a45ee5fb4adf008b3d94
Fix some warnings flagged by Clippy.
1. Elide `.into_iter()` where it's unnecessary.
2. Favor `&` over `.iter()`.
3. Use `.values()` on maps instead of discarding keys by destructuring.
4. Avoid `::from_iter(…)` in favor of `.collect()`.
I also replaced a call to `.cloned()` with `.copied()`.
V3_GIT_ORIGIN_REV_ID: 7d39665b0cd04f5bae9405c0ff5f044f57433f32
Bumps [schemars](https://github.com/GREsau/schemars) from 0.8.19 to
0.8.20.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/GREsau/schemars/releases">schemars's
releases</a>.</em></p>
<blockquote>
<h2>v0.8.20</h2>
<h3>Fixed:</h3>
<ul>
<li>Revert unintentional change in behaviour when combining
<code>default</code> and <code>required</code> attributes (<a
href="https://redirect.github.com/GREsau/schemars/issues/292">GREsau/schemars#292</a>)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/GREsau/schemars/blob/master/CHANGELOG.md">schemars's
changelog</a>.</em></p>
<blockquote>
<h2>[0.8.20] - 2024-05-18</h2>
<h3>Fixed:</h3>
<ul>
<li>Revert unintentional change in behaviour when combining
<code>default</code> and <code>required</code> attributes (<a
href="https://redirect.github.com/GREsau/schemars/issues/292">GREsau/schemars#292</a>)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="7ecaa7feab"><code>7ecaa7f</code></a>
Revert unintentional change in behaviour when combining
<code>default</code> and `requir...</li>
<li><a
href="cf5be1b266"><code>cf5be1b</code></a>
Ignore failing test</li>
<li><a
href="449bb1a0ca"><code>449bb1a</code></a>
Add more tests for different schema settings</li>
<li>See full diff in <a
href="https://github.com/GREsau/schemars/compare/v0.8.19...v0.8.20">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
V3_GIT_ORIGIN_REV_ID: 0a55128d53088b9b0c8c8f2dc5fb03de8af09413
Bumps [rmp-serde](https://github.com/3Hren/msgpack-rust) from 1.1.2 to
1.3.0.
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/3Hren/msgpack-rust/commits/rmp-serde/v1.3.0">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
V3_GIT_ORIGIN_REV_ID: c03bfaa8c506b69a06b9a0563ce2e70df21df11e
Bumps [serde](https://github.com/serde-rs/serde) from 1.0.201 to
1.0.202.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/serde-rs/serde/releases">serde's
releases</a>.</em></p>
<blockquote>
<h2>v1.0.202</h2>
<ul>
<li>Provide public access to RenameAllRules in serde_derive_internals
(<a
href="https://redirect.github.com/serde-rs/serde/issues/2743">#2743</a>)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="9e32a40b1c"><code>9e32a40</code></a>
Release 1.0.202</li>
<li><a
href="87f635e54d"><code>87f635e</code></a>
Release serde_derive_internals 0.29.1</li>
<li><a
href="d4b2dfbde2"><code>d4b2dfb</code></a>
Merge pull request <a
href="https://redirect.github.com/serde-rs/serde/issues/2743">#2743</a>
from dtolnay/renameallrules</li>
<li><a
href="f6ab0bc56f"><code>f6ab0bc</code></a>
Provide public access to RenameAllRules in serde_derive_internals</li>
<li><a
href="48cc2a6327"><code>48cc2a6</code></a>
Replace use of a syn From impl</li>
<li><a
href="3202a6858a"><code>3202a68</code></a>
Skip rerunning build script on library code changes</li>
<li>See full diff in <a
href="https://github.com/serde-rs/serde/compare/v1.0.201...v1.0.202">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Anon Ray <ecthiender@users.noreply.github.com>
V3_GIT_ORIGIN_REV_ID: f6b8f6681b607a89712676456bd688a4b3cb89c3
`axum::Json` can work with any serializable type. Constructing a
`serde_json::Value` using `json!` just adds an intermediate step,
slowing down the conversion from structured data to the response bytes.
V3_GIT_ORIGIN_REV_ID: 8ae6352cb9a576988df5bf417e78d64706c7eb6e
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
## 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
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
<!-- 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
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
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
<!-- 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
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
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
Bumps [nonempty](https://github.com/cloudhead/nonempty) from 0.8.1 to
0.10.0.
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/cloudhead/nonempty/commits">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
V3_GIT_ORIGIN_REV_ID: 11c6454b5e7e9877b52075f0e0efe6839ecf3be1
<!-- Thank you for submitting this PR! :) -->
## Description
Following the approach taken here:
https://github.com/hasura/ndc-postgres/pull/402
This moves the `clippy` settings into the Cargo workspace file instead
of passing them for each invocation.
We enable all pedantic settings, run `cargo clippy --fix` to auto fix a
few things, and then manually disable all other lints.
Plenty of them are worth enabling and fixing in future IMO.
---------
Co-authored-by: Samir Talwar <samir.talwar@hasura.io>
V3_GIT_ORIGIN_REV_ID: aa0e6ccb8d72a7393e14b5c58b82077a67d9cb15
<!-- Thank you for submitting this PR! :) -->
## Description
I have upgraded ndc-spec to v0.1.1. This pulls in an upgrade to
opentelemetry v0.22 so I've done that too.
We had issues with the `traceresponse` response header disappearing when
using an opentelemetry version > v0.20. This seems to be resolved here,
probably because we have pinned a single version of opentelemetry rather
than loading multiple at once. I added the `traceresponse` header to
verify this, and have left it in because it doesn't seem to hurt
anything.
I verified that everything works as expected with the OSS components,
but not multitenant.
## 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
-->
v3 engine GraphQL queries now include a "traceresponse" header.
<!-- changelog-entry : end : DO NOT REMOVE -->
<!-- changelog : end : DO NOT REMOVE -->
V3_GIT_ORIGIN_REV_ID: f37b6bdb1331b55c49f0bd953f522f5eca298d1d
`cargo machete` is a very useful tool that figures out when you aren't
using a dependency. I have run this locally to remove unused
dependencies.
I've also added a CI job to make sure we catch these in the future.
Sometimes it reports false positives, e.g. when a dependency isn't used
directly but in macro-generated code (e.g. with `strum`). I have added
`"ignored"` clauses to the `Cargo.toml` files where appropriate.
V3_GIT_ORIGIN_REV_ID: ed015089b695cec8eeb03ce455d6dd3cd312a016
When there are no allowed fields for a type (via `TypePermissions`),
engine creates related input object types (like `<TypeName>OrderBy`)
with no fields. This results in an invalid introspection result. Client
libraries fail with validation error.
This PR fixes the issue.
V3_GIT_ORIGIN_REV_ID: a45a56b1f503f6ab99f250884957b6fc723cf9c8
This was a simple solution to prevent crashes from the cases that I was
able to discover, refactored into a macro that can be used elsewhere;
but I suspect there's a more idiomatic rust solution
(entailing a big refactor?). There's also the stacker crate, and see
also discussion here:
https://hasurahq.slack.com/archives/C04PUMV4X16/p1707337409839869?thread_ts=1701302324.058369&cid=C04PUMV4X16
Note that the compiled binary was built and fuzzed with `--release`.
Many discovered cases caused crashes when run into non-optimized binary
(probably stack overflows but I did not look into it)
V3_GIT_ORIGIN_REV_ID: 31acfc9e358c807be80ba6a5efa78ace78306291
<!-- Thank you for submitting this PR! :) -->
## Description
This PR adds the capability to expose _entities and _service fields.
Apollo Federation uses these fields to extend types in other subgraphs
using the types from a subgraph. We can now use Hasura v3 as a subgraph
in an Apollo federated supergraph.
To make this possible, we had to do the following metadata changes:
- Add `apolloFederation` in `ObjectType.graphql`:
```yaml
apolloFederation:
keys:
- fields:
- id
```
- Add `apolloFederation` in `Model.graphql`:
```yaml
apolloFederation:
entitySource: true
```
- Add `apolloFederation` in `GraphqlConfig`:
```yaml
apolloFederation:
enableRootFields: true
```
https://github.com/hasura/v3-engine/assets/85472423/b3223c61-360a-4ed6-b8ab-b394469957ce
RFC:
https://github.com/hasura/graphql-engine/pull/10141/files#diff-a9f74850aca6ecad1556723e4b3c7395e59f26cd40d9de20bfef83cb9c64f028
## 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: 73cb9e6c8ef4bfe64d0f0cd9ce3ccbd32e208712
