- Introduce a field in NDC `Configuration` struct that carries an
optional limit (`usize`) value.
- When set, reject NDC response that is greater than the limit.
- Define a `HttpContext` struct that captures both `reqwest::Client` and
an optional limit value. Replace the `http_client` argument with
`http_context: &HttpContext` in all execute related functions.
- The `execute_query` function caller in multitenant code need to pass a
reference to `HttpContext` with appropriate NDC response size limit.
V3_GIT_ORIGIN_REV_ID: 85a3647c4d136cc8d887f343736cc011166f036f
<!-- Thank you for submitting this PR! :) -->
## Description
Set our `ndc-postgres` connector in tests to use new mutations versions
so we can test Boolean Expressions. Also does some house-keeping, like
ensuring we pull the latest `ndc-postgres` in CI and exposing `8080`
from `ndc-postgres` to fix local dev flow.
V3_GIT_ORIGIN_REV_ID: 4c92670e9976a3f75ec31e1224079799380ef6e2
<!-- Thank you for submitting this PR! :) -->
## Description
We'll shortly be adding `BooleanExpression` to `ValueExpression`, which
will require resolving the internal `ModelPredicate`. This PR adds a
resolving step for `ValueExpression` to simplify that later step. It is
essentially a no-op to introduce a new type.
V3_GIT_ORIGIN_REV_ID: 8bfe4a180e12ae50d8f131072886054c0e618ec4
- Move redundant code in `client.rs` into a separate function.
- Doc utility functions through comments
V3_GIT_ORIGIN_REV_ID: f172ec2309b48c627f4ab9179efcb4c278e82989
This seems appropriate now that we've stabilized the new configuration.
Of note are the configuration updates and the use of an environment
variable to specify the connection URI. This upgrade also fixes the
health checks.
Regenerating the configuration lost the table descriptions, which seems
to be because they were not present in the Chinook SQL. I have dragged
the Chinook SQL in from ndc-postgres and kept it separate from the
initialization of other tables.
The auto-generated configuration is slightly different from the
manually-created configuration in that the collection names are
singular, not plural. This means that I had to change a lot of test
metadata files too.
V3_GIT_ORIGIN_REV_ID: 2b66fd3049aaf4daeb386915ea3b64a209b1f393
- Adds titles to json schemas where missing
- Adds tests to ensure we don't miss titles in the future (modulo some
exceptions)
This is required to be able to autogenerate the docs for the metadata
V3_GIT_ORIGIN_REV_ID: e2027f3e3d5ee3546af99ff5c2d6de59604a3aec
Ref: https://github.com/hasura/ndc-spec/pull/130
- Avoid using NDC client code from ndc-spec for ndc API requests.
Instead, copy the client related code from ndc-spec into v3-engine.
- Code is copied into `.../execute/ndc/client.rs` module with the
following changes:
- API, configuration and error type related code is consolidated into a
single `client.rs` module.
- Derive error implementation for the error type using
`thiserror::Error` derive-macro
- Replace `opentelemetry` crate usage with `tracing_util` with necessary
changes
- Lot of redundant logic still there which will be addressed through
https://hasurahq.atlassian.net/browse/APG-53
V3_GIT_ORIGIN_REV_ID: 5766e407495c483cc4814d1286121b233aed3af0
I am struggling to diagnose some errors and `.unwrap` is not helping, as
it doesn't properly capture stack traces or anything else that might be
useful.
`anyhow` was built for this. Let's use it.
I had to convert `SessionError` to a real `Error`, which I don't think
is a bad thing.
V3_GIT_ORIGIN_REV_ID: 3b8a70bb87e12e7b9e39515cd5f769fbd2cbfb39
<!-- Thank you for submitting this PR! :) -->
## Description
When I run `cargo fmt` on my branches, it makes more diff than I want.
This PR fixes that by adding `just format` / `just fmt`, and adding it
to a CI job.
<!--
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: e31e352f27b9ad0129c3759fead051b1a8d86758
## Description
Listening on `0.0.0.0` only binds to IPv4 addresses. We can listen on
IPv4 and IPv6 by using `::`.
I have opted to use the constants for this rather than parsing a string,
both for clarity and to avoid errors.
## 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 now binds to all IPv4 and IPv6 addresses. Previously it
only used IPv4.
<!-- changelog-entry : end : DO NOT REMOVE -->
<!-- changelog : end : DO NOT REMOVE -->
V3_GIT_ORIGIN_REV_ID: d63b5544bfbf2ad067113980fa61dd74213c7b78
If we're running a mockito server in async tests, we must use
`new_async`.
The latest version enforces this.
V3_GIT_ORIGIN_REV_ID: cb58f248336c7bab08329d311b8b97b8244437a1
Most of our span names were in the format `snake_case` and usually
reflected `name_of_the_function`. This is unfriendly, so we've changed
it to match the format used by data connectors, which use a format like
"Database request" or "Waiting for connection".
It would be nice if `Execute request plan for query field` could be
`Execute request plan for query field "person"` but it seems changing
the currently used `&'static str` for `String` causes all sorts of other
lifetime issues, so I suppose we're better including more information as
span attributes instead. Therefore, all our span names need to be pretty
much static (or at least, dynamically chosen from a list of static
names).
Note: I have not changed the `SpanVisibility::Internal` span names for
now. Most of these reflect function names and this is pretty useful IMO.
Happy to change this later if other feel strongly though.
V3_GIT_ORIGIN_REV_ID: f2226b2466e8592676f3f4635d483289f0e3f6aa
<!-- 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
`IndexMap::remove` has been deprecated in favor of
`IndexMap::swap_remove` (which has the same behavior, but is clearer
about breaking ordering) or `IndexMap::shift_remove`, which retains
order but is O(n) complexity.
I have taken a look at the areas where we use `.remove`. Where we
discard the map afterwards, I've changed it to `.swap_remove`. In one
case, we do return the data in the event of error, but we probably care
more about consistency of ordering than the actual precise order, so
I've used a `HashMap` and just sorted it instead.
V3_GIT_ORIGIN_REV_ID: 479e1013a4a9938f973b5ed85dbf3837896151e4
## Description
In order to implement transactions for the connectors that allow it, we
want to group mutation commands by connector. Then, we can execute a
group in a single transaction if possible, else just loop through it as
we always have. Grouping by connector also means we can access things
like capabilities for whole batches at a time.
## 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: 928715b78b214a3ac2452e8d1e5f33c87b20de33
<!-- Thank you for submitting this PR! :) -->
## Description
For some reason, `cargo test` fails because of missing types in doc
comment code, but `cargo nextest run` in CI does not. Re-adding `axum`
as a dep dependency to `tracing-util` fixes this.
---------
Co-authored-by: Samir Talwar <samir.talwar@hasura.io>
V3_GIT_ORIGIN_REV_ID: 518e6faf702895d9c434056a57c40c2db6f4b0a8
<!-- Thank you for submitting this PR! :) -->
## Description
My memory is bad and I want to make it easy to run the `engine` to try
it out. This adds the `just run-local` command which uses the schema
from the tests (and so is very likely to continue working).
<img width="1445" alt="Screenshot 2024-03-28 at 09 44 46"
src="https://github.com/hasura/v3-engine/assets/4729125/5dc9a8d6-612e-418e-be24-ef0fefd0da99">
V3_GIT_ORIGIN_REV_ID: b5cd009b19805f5e9ed6180f68878207ece50d98
`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
- Use `rust-toolchain.toml` to specify tools.
- Drop the unused version field from the compose files.
- Use a modern Docker base for the dev-auth-webhook.
- Handle signals in the test servers so `docker stop` is quick.
- Upgrade Jaeger.
V3_GIT_ORIGIN_REV_ID: b5fee1d5dc953a1fdb0aabd75ba02df6846b7518
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
Give types / titles to all maps in the metadata jsonschema
This helps in automatically generating the metadata docs page. Without a
title/type it's hard to refer to what is the type of the fields which
have a map type.
V3_GIT_ORIGIN_REV_ID: 8d13012b95910be13fdee6a7af1372f7b6cf2b89
An upcoming version of ndc-spec will split out this module as a new
crate named `ndc_models`. This PR gets ahead of this change by aliasing
so that we can simply delete the `use` lines in the future.
This is a very boring, mechanical change that does not modify any
behavior at all.
V3_GIT_ORIGIN_REV_ID: 078d3f5fbc2961fcd93b924134de40ba693f0061
Fixes descriptions defined on `ObjectType`s and their fields in metadata
not showing up when that type is expressed as an input object type in
GraphQL.
V3_GIT_ORIGIN_REV_ID: de5cb2d545441fdebdf85fa84c90e9f0a4cbaac7
If we're going to be unstable, let's go all the way.
This change was motivated by needing to upgrade cargo-machete to make it
work with Rust v1.77, and not having the upgrade in nixos-unstable.
V3_GIT_ORIGIN_REV_ID: 8191a376a6aeebc08787f973d58d373f8ab9ad0d
<!-- Thank you for submitting this PR! :) -->
## Description
`check_conflicting_graphql_types` actually inserts a new GraphQL type
into a set (and explodes on failure).
Renamed to `store_new_graphql_type` which I feel is a bit clearer.
V3_GIT_ORIGIN_REV_ID: 4b774b9cd9e479c16f3de8af4df263f97cfab107
## Description
We don't need the per-node mutation plan because, where at all possible,
we won't run per-node mutations. This change doesn't change the
behaviour of anything, but changes the structure of mutation plans to be
whole-request, rather than per-node.
## 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: 9accc9696fabd05f992c6245ccc411a781cf5790
<!-- Thank you for submitting this PR! :) -->
## Description
Missed this in https://github.com/hasura/v3-engine/pull/355, apologies.
V3_GIT_ORIGIN_REV_ID: 360b4a3a218f6ba754814c5b3083a8151a7886fb
For remote joins, if join field already exists in the selection set, do
not request it again. Include the join field only if it is not in the
selection set.
A field selection might be expensive, so we do not want to duplicate it.
Fixes: https://hasurahq.atlassian.net/browse/V3API-296
V3_GIT_ORIGIN_REV_ID: d09e4298557ca098433b0758c15703295ccbfd39
<!-- Thank you for submitting this PR! :) -->
## Description
As noted in https://github.com/hasura/v3-engine/pull/398, the metadata
resolver works by passing a lot of mutable references around, making the
flow of data quite difficult to follow. This changes the passing of
`types` to make it more explicit. Where possible, any mutation is pushed
up to the top-level, or we return owned values.
V3_GIT_ORIGIN_REV_ID: 61251929cbc9b9410fabba85b58738037dfcb586
## Description
Fixes various spelling errors in the JSON schema descriptions.
No behavioural changes.
V3_GIT_ORIGIN_REV_ID: 56454b3193baa8257caa6116a35fbdda4be1d5eb
<!-- Thank you for submitting this PR! :) -->
## Description
Was trying to work out where mutation was happening in this massive
function, so broke it up into lots of smaller functions so it's easier
to tell from the inputs what is going on. There is definitely lots of
room for improvement here, have avoided making any functional changes in
lieu of just mechanically moving the code.
Behavioural no-op.
V3_GIT_ORIGIN_REV_ID: 19fa239319d348d486eb18e15d62614d6af2bd9b
<!-- Thank you for submitting this PR! :) -->
## Description
The `Error` enum in `resolved/error.rs` is absolutely giant. Going to
break it down into smaller structures, this is the first of those. There
are probably some missing items in here, but I am starting with rough
cuts and expect the right place for everything to appear over time.
No behavioural change.
V3_GIT_ORIGIN_REV_ID: 69d4ae880ad9cbffdc66adde10996e9f92cee8f4
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/10741
Co-authored-by: Aravind K P <8335904+scriptonist@users.noreply.github.com>
Co-authored-by: Mohd Bilal <24944223+m-Bilal@users.noreply.github.com>
GitOrigin-RevId: 1008b4abfb0fe12c5c7fdbdbe47a0820435b595c
