<!-- The PR description should answer 2 important questions: -->
### What
Given a model name `Authors` with an `Author` type underneath, this
changes field selection for JSONAPI to use `fields[Author]` instead of
`fields[Authors]`.
This will make things more consistent when we are also filtering other
types from relationships or nested fields too, which will have to use
type names, for example
`fields[Author]=name,articles&fields[Article]=title`
V3_GIT_ORIGIN_REV_ID: fff43c673888877ca8b2edb6e5ca9fdc846675a5
<!-- The PR description should answer 2 important questions: -->
### What
These have been deprecated for a while, and we now have a codemod to fix
users metadata, so it's time to make these officially deprecated. Any
`ObjectBooleanExpressionType` will now raise an error.
V3_GIT_ORIGIN_REV_ID: f3dd18afba40e369e82a15a7fbbfe31004d44067
<!-- The PR description should answer 2 important questions: -->
### What
Previously the OpenDD pipeline has ignored `BooleanExpressionType` as
they were not available outside GraphQL. Now they are, so we use them,
and test them in the JSONAPI pipeline.
This means that the SQL frontend cannot use filtering unless models have
a `BooleanExpressionType` defined. These are generated by the CLI, so
hopefully this is fine.
Depends on #1336
V3_GIT_ORIGIN_REV_ID: 4037585ef36bc99c99a482361084ccd09c5c6bb1
### What
This PR does three related things:
* Adds an execution test that tests that nested relationships work in
field selection in Postgres (taken from #935)
* Refactors the way capabilities are handled in metadata resolve to
account for difference between NDC 0.1.x and 0.2.x. Specifically, NDC
0.1.x connectors are assumed to support nested relationships in field
selection, but do not support them in filtering and ordering. Whereas in
NDC 0.2.x, a capability exists to indicate nested relationship support,
but then you must support them in filtering and ordering as well as
field selection.
* Updates the metadata used in the default docker compose so that it:
* uses an up to date pg schema
* uses BooleanExpressionType instead of ObjectBooleanExpression
* removes commands that do not exist on the pg connector
* adds the Institutions model so that nested relationships can be tested
This PR does not add support for nested relationships in filtering or in
ordering. It also does not block nested relationships in field selection
for NDC 0.2.x connectors that do not support it. This will all come in
later PRs.
### How
In `metadata_resolve`, the resolved `DataConnector` used to contain a
copy of the `ndc_models::Capabilities`. This has been removed and
instead a `metadata_resolve` specific `DataConnectorCapabilities`
structure is used instead. This decouples `metadata_resolve` from
`ndc_models` and allows it to capture differences between NDC 0.1.x and
0.2.x properly.
There is now a specific function per NDC version that creates a
`DataConnectorCapabilities`. This removes the need for capabilities
migration code.
V3_GIT_ORIGIN_REV_ID: 0eb119aab0e5fa22977d84820025f75c6102036d
<!-- The PR description should answer 2 important questions: -->
### What
Operator mappings in boolean expressions allow us to override the name
of an operator, so we can call some database's `_eq` operator the much
more attractive `equals`. If not override is provided we can just use
the database's name directly. We make this a newtype with a `get`
function to encode this logic and make doing the right thing the easiest
thing.
V3_GIT_ORIGIN_REV_ID: e47f4e291494562ed1551d0d7469259198862a0a
<!-- The PR description should answer 2 important questions: -->
### What
<!-- What is this PR trying to accomplish (and why, if it's not
obvious)? -->
<!-- Consider: do we need to add a changelog entry? -->
<!-- Does this PR introduce new validation that might break old builds?
-->
<!-- Consider: do we need to put new checks behind a flag? -->
Send `type: ping` messages on a websocket connection at regular
intervals to avoid keeping it idle.
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
- Spawn an async thread that send the ping messages at regular
intervals.
- Abort the thread before closing a connection.
A test case is written to confirm the keepalive messsage sent. Also this
PR does a tiny no-op refactor to the `expect_text_message` helper
function in the graphql-ws tests.
V3_GIT_ORIGIN_REV_ID: 65b02cf1f6502bd3a6a9460673e3d87f24738d33
<!-- The PR description should answer 2 important questions: -->
### What
<!-- What is this PR trying to accomplish (and why, if it's not
obvious)? -->
<!-- Consider: do we need to add a changelog entry? -->
<!-- Does this PR introduce new validation that might break old builds?
-->
<!-- Consider: do we need to put new checks behind a flag? -->
Set the `request.type` attribute in the opening spans to determine the
request type, either http or websocket.
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
Define an enum type to capture the request type and set its `to_str()`
value in the `request.type` attribute.
V3_GIT_ORIGIN_REV_ID: d0370d8a5b7938a546a74641bf7bfee6da2dd33f
<!-- The PR description should answer 2 important questions: -->
### What
<!-- What is this PR trying to accomplish (and why, if it's not
obvious)? -->
<!-- Consider: do we need to add a changelog entry? -->
<!-- Does this PR introduce new validation that might break old builds?
-->
<!-- Consider: do we need to put new checks behind a flag? -->
Disallow duplicate root fields in a model GraphQL config. This is a
backward incompatible change which could break any existing builds with
duplicate root fields. Hence, this check is guarded behind a
compatibility date. However, warnings are thrown during a build if
metadata contains duplicate graphql root fields.
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
Add a check while resolving the graphql metadata of a model definition.
V3_GIT_ORIGIN_REV_ID: d083c62fa359df8742bbc16df821d46275d29e79
<!-- The PR description should answer 2 important questions: -->
### What
Our Nix build was building all the workspace crates as part of it's deps
step. This means when any library crate is changed, we throw away all
the caching, which isn't ideal. This filters the source files out of
those builds, so that we get more cache hits. We also move all Cargo
features into the workspace, which I've been meaning to do for ages, so
things are more consistent, and again, we get more cache hits generally.
V3_GIT_ORIGIN_REV_ID: c724b152692575edf6c00ab426e48ecca13aa998
<!-- The PR description should answer 2 important questions: -->
### What
We only resolve boolean expression fields if there is a `graphql` name
defined, which is not helpful for using them in JSONAPI or SQL. This
makes the validation happen earlier.
This means users that have broken boolean expressions that did not have
a `graphql` field would have been allowed to sit broken, but now those
will error, so this is behind a new compatibility config flag.
### How
Move `scalar_fields` and `object_fields` resolve into `object` steps
instead of the `graphql` steps of resolve for
`ObjectBooleanExpressionType` and `BooleanExpressionType`.
Note: we really need to get `ObjectBooleanExpressionType` deprecated and
deleted, it causes so much extra work and complexity everywhere.
V3_GIT_ORIGIN_REV_ID: c6f0849d412b40f3484fb44c1b36ebdf77ac60c1
We get a 17% reduction in size for chinook.json, 14% for our big schema.
Benchmark is 8% faster for chinook.json
<!-- The PR description should answer 2 important questions: -->
### What
reduce artifact size
### How
remove certain common "default" fields on serialization, to be
repopulated on deserialization. Since this works at the serde level we
should still benefit if we manage to switch to e.g. bincode
I attempted to create a macro for this, but decided it wasn't worth it.
Fields were chosen by sorting and counting json fields, and adding these
annotations for the heaviest ones.
V3_GIT_ORIGIN_REV_ID: 4605016021fa6aafb97759e3bd5346116413a0ef
<!-- The PR description should answer 2 important questions: -->
### What
<!-- What is this PR trying to accomplish (and why, if it's not
obvious)? -->
<!-- Consider: do we need to add a changelog entry? -->
<!-- Does this PR introduce new validation that might break old builds?
-->
<!-- Consider: do we need to put new checks behind a flag? -->
No-op refactor. Just updates the error message.
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
Define a type to track root fields and report error if the field is
already in use.
V3_GIT_ORIGIN_REV_ID: 91533ee0dd48087617e1950f1aeb42a1787edc16
### What
This PR updates the engine to use the NDC Spec v0.2.0-rc.1 version. This
is very likely to be the final RC before release.
### How
The `ndc_models` crate got updated, which then resulted in the schema
migration code in `metadata_resolve` being updated. This affected a lot
of test results because connectors that used deprecated type
representations got migrated to other representations, and if a type
representation was missing then JSON was used instead.
The NDC request-sending code in `execute` was updated to send the
`X-Hasura-NDC-Version` header depending on the version of request
getting sent.
The custom connector was updated to be compatible with the new NDC
0.2.0-rc.1 types. This resulted in the schema changing, so a lot of
tests that contained the connector's schema were updated.
---------
Co-authored-by: Daniel Harvey <danieljamesharvey@gmail.com>
V3_GIT_ORIGIN_REV_ID: b1c7081eb1ee6cffdead08328a857903102332c6
<!-- The PR description should answer 2 important questions: -->
### What
These are no longer used since
https://github.com/hasura/v3-engine/pull/1301, let's remove them from
the metadata.
V3_GIT_ORIGIN_REV_ID: 17194f7fa30860738e99de6098fa84d212fee0d2
<!-- The PR description should answer 2 important questions: -->
### What
First iteration of JSONAPI filtering
What does it do?
- Field comparisons against values
- And
- Or
What doesn't it do
- Generate schema
- Use `BooleanExpressionType` to work out which operators are available
- Work for nested fields (which don't work anyway atm)
V3_GIT_ORIGIN_REV_ID: 71f490b2767275b5e57fa4bcf213f2339391c093
<!-- The PR description should answer 2 important questions: -->
### What
Accidentally made the fallthrough to show all fields too liberal, so our
"include this field?" function became const true. Now we check properly.
V3_GIT_ORIGIN_REV_ID: a56ce76e1cdf57ea17856b9835128f75b3cf18c3
<!-- The PR description should answer 2 important questions: -->
### What
<!-- What is this PR trying to accomplish (and why, if it's not
obvious)? -->
<!-- Consider: do we need to add a changelog entry? -->
<!-- Does this PR introduce new validation that might break old builds?
-->
<!-- Consider: do we need to put new checks behind a flag? -->
Fix a bug with pollers are not being stopped when the connection is
dropped.
### How
Fetch all poller operation ids at once from a mutex map and stop each
poller associated with them in a for-loop.
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
V3_GIT_ORIGIN_REV_ID: f17511d611b92ace3de2c83e606d26214649878b
<!-- The PR description should answer 2 important questions: -->
### What
JSONAPI builds iterate over `roles` in metadata, and one was very slow,
realised it was because it was calculating for `admin` over and over.
This changes the `roles` in `metadata-resolve` to be collected in a
`BTreeSet` to remove duplicates, which fixes the problem.
### How
Change `Vec` to `BTreeSet`, fix type errors and snapshots.
V3_GIT_ORIGIN_REV_ID: c61ef9e490c3cde9d004c08ef71dc73e92cd6e7e
Bumps [derive_more](https://github.com/JelteF/derive_more) from 0.99.18
to 1.0.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/JelteF/derive_more/releases">derive_more's
releases</a>.</em></p>
<blockquote>
<h2>v1.0.0 - Finally a stable release</h2>
<p><code>derive_more</code> is a library that adds derives for many of
the standard library traits. By using this library the following code
just works:</p>
<pre lang="rust"><code>use derive_more::{Add, Display, From, Into};
<p>#[derive(PartialEq, From, Add)]
struct MyInt(i32);</p>
<p>#[derive(PartialEq, From, Into)]
struct Point2D {
x: i32,
y: i32,
}</p>
<p>#[derive(PartialEq, From, Add, Display)]
enum MyEnum {
#[display("int: {_0}")]
Int(i32),
Uint(u32),
#[display("nothing")]
Nothing,
}</p>
<p>assert!(MyInt(11) == MyInt(5) + 6.into());
assert!((5, 6) == Point2D { x: 5, y: 6 }.into());
assert!(MyEnum::Int(15) == (MyEnum::Int(8) + 7.into()).unwrap());
assert!(MyEnum::Int(15).to_string() == "int: 15");
assert!(MyEnum::Uint(42).to_string() == "42");
assert!(MyEnum::Nothing.to_string() == "nothing");
</code></pre></p>
<p>Now, more than 8 years after the first commit and almost 5 years
after the 0.99.0 release, <code>derive_more</code> has finally reached
its 1.0.0 release. This release contains a lot of changes (including
some breaking ones) to make it easier to use the derives and make it
possible to extend them without having to break backwards compatibility
again. There are five major changes that I would like to call out, but
there are many more changes that are documented below:</p>
<ol>
<li>There is a new <code>Debug</code> derive that can be used to easily
customize <code>Debug</code> formatting.</li>
<li>A greatly improved <code>Display</code> derive, which allows you to
do anything that <a
href="https://github.com/dtolnay/thiserror"><code>thiserror</code></a>
provides, but it works for any type not just errors. And by combining
the <code>Display</code> derive with the <code>Error</code> and
<code>From</code> derives, there shouldn't really be any need to use
<code>thiserror</code> anymore (if you are missing a feature/behaviour
from <code>thiserror</code> please report an issue).</li>
<li>Traits that can return errors now return a type that implements
<code>Error</code> when an error occurs instead of a <code>&'static
str</code>.</li>
<li>When using <code>use derive_more::SomeTrait</code> the actual trait
is also imported not just the derive macro. This is especially useful
for <code>Error</code> and
<code>Display</code></li>
<li>The docs are now rendered on docs.rs and are much better
overall.</li>
</ol>
<h3>Breaking changes</h3>
<ul>
<li>The minimum supported Rust version (MSRV) is now Rust 1.75.</li>
<li>Add the <code>std</code> feature which should be disabled in
<code>no_std</code> environments.</li>
<li>All Cargo features, except <code>std</code>, are now disabled by
default. The <code>full</code> feature can be used to get the old
behavior of supporting all possible derives.</li>
<li>The <code>TryFrom</code>, <code>Add</code>, <code>Sub</code>,
<code>BitAnd</code>, <code>BitOr</code>, <code>BitXor</code>,
<code>Not</code> and <code>Neg</code> derives now return a dedicated
error type instead of a <code>&'static str</code> on error.</li>
<li>The <code>FromStr</code> derive now uses a dedicated
<code>FromStrError</code> error type instead of generating unique one
each time.</li>
<li>The <code>Display</code> derive (and other <code>fmt</code>-like
ones) now uses <code>#[display("...",
(<expr>),*)]</code> syntax instead of <code>#[display(fmt =
"...", ("<expr>"),*)]</code>, and
<code>#[display(bound(<bound>))]</code> instead of
<code>#[display(bound = "<bound>")]</code>. So without
the double quotes around the expressions and bounds.</li>
<li>The <code>Debug</code> and <code>Display</code> derives (and other
<code>fmt</code>-like ones) now transparently delegate to the inner type
when <code>#[display("...", (<expr>),*)]</code>
attribute is trivially substitutable with a transparent call. (<a
href="https://redirect.github.com/JelteF/derive_more/pull/322">#322</a>)</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/JelteF/derive_more/blob/master/CHANGELOG.md">derive_more's
changelog</a>.</em></p>
<blockquote>
<h2>1.0.0 - 2024-08-07</h2>
<p>More than 8 years after the first commit and almost 5 years after the
0.99.0
release, <code>derive_more</code> has finally reached its 1.0.0 release.
This release
contains a lot of changes (including some breaking ones) to make it
easier to
use the derives and make it possible to extend them without having to
break
backwards compatibility again. There are five major changes that I would
like
to call out, but there are many more changes that are documented
below:</p>
<ol>
<li>There is a new <code>Debug</code> derive that can be used to easily
customize <code>Debug</code>
formatting.</li>
<li>A greatly improved <code>Display</code> derive, which allows you to
do anything that
<a
href="https://github.com/dtolnay/thiserror"><code>thiserror</code></a>
provides, but it works
for any type not just errors. And by combining the <code>Display</code>
derive with the
<code>Error</code> and <code>From</code> derives, there shouldn't really
be any need to use
<code>thiserror</code> anymore (if you are missing a feature/behaviour
from <code>thiserror</code>
please report an issue).</li>
<li>Traits that can return errors now return a type that implements
<code>Error</code>
when an error occurs instead of a <code>&'static str</code>.</li>
<li>When using <code>use derive_more::SomeTrait</code> the actual trait
is also imported
not just the derive macro. This is especially useful for
<code>Error</code> and
<code>Display</code></li>
<li>The docs are now rendered on docs.rs and are much better
overall.</li>
</ol>
<h3>Breaking changes</h3>
<ul>
<li>The minimum supported Rust version (MSRV) is now Rust 1.75.</li>
<li>Add the <code>std</code> feature which should be disabled in
<code>no_std</code> environments.</li>
<li>All Cargo features, except <code>std</code>, are now disabled by
default. The <code>full</code>
feature can be used to get the old behavior of supporting all possible
derives.</li>
<li>The <code>TryFrom</code>, <code>Add</code>, <code>Sub</code>,
<code>BitAnd</code>, <code>BitOr</code>, <code>BitXor</code>,
<code>Not</code> and <code>Neg</code>
derives now return a dedicated error type instead of a
<code>&'static str</code> on
error.</li>
<li>The <code>FromStr</code> derive now uses a dedicated
<code>FromStrError</code> error type instead
of generating unique one each time.</li>
<li>The <code>Display</code> derive (and other <code>fmt</code>-like
ones) now uses
<code>#[display("...", (<expr>),*)]</code> syntax
instead of
<code>#[display(fmt = "...",
("<expr>"),*)]</code>, and
<code>#[display(bound(<bound>))]</code>
instead of <code>#[display(bound = "<bound>")]</code>.
So without the double quotes
around the expressions and bounds.</li>
<li>The <code>Debug</code> and <code>Display</code> derives (and other
<code>fmt</code>-like ones) now transparently
delegate to the inner type when <code>#[display("...",
(<expr>),*)]</code> attribute is
trivially substitutable with a transparent call.
(<a
href="https://redirect.github.com/JelteF/derive_more/pull/322">#322</a>)</li>
<li>The <code>DebugCustom</code> derive is renamed to just
<code>Debug</code> (gated now under a separate
<code>debug</code> feature), and its semantics were changed to be a
superset of <code>std</code> variant
of <code>Debug</code>.</li>
<li>The <code>From</code> derive doesn't derive
<code>From<()></code> for enum variants without any
fields anymore. This feature was removed because it was considered
useless in</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="d7f5b9e94d"><code>d7f5b9e</code></a>
chore: Release</li>
<li><a
href="40201b1e2e"><code>40201b1</code></a>
Update release date to be correct</li>
<li><a
href="88863ca4e6"><code>88863ca</code></a>
Update changelog wording</li>
<li><a
href="b713835894"><code>b713835</code></a>
Improve error when not enabling any features</li>
<li><a
href="330e4252fb"><code>330e425</code></a>
Order features in Cargo.toml alphabetically</li>
<li><a
href="84f2cbb05f"><code>84f2cbb</code></a>
Update README and CHANGELOG in preparation of 1.0.0</li>
<li><a
href="e8d60cf0e5"><code>e8d60cf</code></a>
Add compile_fail test for on purpose limited bounds (<a
href="https://redirect.github.com/JelteF/derive_more/issues/393">#393</a>,
<a
href="https://redirect.github.com/JelteF/derive_more/issues/392">#392</a>)</li>
<li><a
href="f665d18125"><code>f665d18</code></a>
Make anyhow reference a bit less strong</li>
<li><a
href="6d632b2db2"><code>6d632b2</code></a>
Add release announcement (<a
href="https://redirect.github.com/JelteF/derive_more/issues/390">#390</a>)</li>
<li><a
href="e87ab1315f"><code>e87ab13</code></a>
Don't create git tags for derive_more-impl (<a
href="https://redirect.github.com/JelteF/derive_more/issues/391">#391</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/JelteF/derive_more/compare/v0.99.18...v1.0.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>
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: Daniel Harvey <danieljamesharvey@gmail.com>
V3_GIT_ORIGIN_REV_ID: 2a5d2033a90d16d5bf2096db5a717e31128b8c00
<!-- The PR description should answer 2 important questions: -->
### What
Lets be a bit more granular about our spans for JSONAPI endpoint.
<img width="1508" alt="Screenshot 2024-10-29 at 16 46 32"
src="https://github.com/user-attachments/assets/97f67ae3-ac27-4dcd-84a4-083dc6ef5e67">
V3_GIT_ORIGIN_REV_ID: d5c0342c0c9dae2f50e78c7f529a54eeedb541a9
<!-- The PR description should answer 2 important questions: -->
### What
Needed to reuse some stuff when putting JSONAPI into multitenant, and
everything is a big tangled mess, so thought it was finally time to
clean up shop. Moves a bunch of stuff from `/bin` into the library in
`src` and splits it into files.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: 87406e3fb63a1f90347782abeda3d4db14386270
<!-- The PR description should answer 2 important questions: -->
### What
A few tweaks to make OpenAPI validators happy.
V3_GIT_ORIGIN_REV_ID: a1ff6c7180f1ee02d0e6f53c83aeeceea964e5d8
<!-- The PR description should answer 2 important questions: -->
### What
<!-- What is this PR trying to accomplish (and why, if it's not
obvious)? -->
<!-- Consider: do we need to add a changelog entry? -->
<!-- Does this PR introduce new validation that might break old builds?
-->
<!-- Consider: do we need to put new checks behind a flag? -->
Consider the possibility of multiple and comma separated header values
when validating the protocol name.
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
V3_GIT_ORIGIN_REV_ID: 4431eda71e6dcbdbcc2df4520af1ed9cbfe8950d
<!-- The PR description should answer 2 important questions: -->
### What
Move `lang-graphql`, `graphql-ws` and `frontends/graphql` into the
`graphql` folder. Functional no-op.
V3_GIT_ORIGIN_REV_ID: c9d6c5db6693dbe9213569443a102a3b3b2e39f6
<!-- The PR description should answer 2 important questions: -->
### What
Add the following metrics for GraphQL websockets:
- active connections
- active pollers
- total connections
<!-- What is this PR trying to accomplish (and why, if it's not
obvious)? -->
<!-- Consider: do we need to add a changelog entry? -->
<!-- Does this PR introduce new validation that might break old builds?
-->
<!-- Consider: do we need to put new checks behind a flag? -->
### How
This is a bit involved that I initially thought. In normal HTTP
requests, metrics are recorded in middleware. In websockets, metrics
have to be recorded in deeper layers of code. So made the websocket
metrics a part of the `Context` as it is available for each connection.
Defined a trait that impls a few methods to record metrics on connection
& poller managements, and use them in relevant code paths.
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
V3_GIT_ORIGIN_REV_ID: bbaf63fd7ef3274bf5fe72bb86aa8e07a28f6fe2
<!-- The PR description should answer 2 important questions: -->
### What
Release `OrderByExpression` and version 2 of `Model`. These have been
working behind feature flags for a while.
### How
Remove feature flags, remove `hidden` pragmas on `open-dds` metadata.
V3_GIT_ORIGIN_REV_ID: dfb7e9316171c11d2605dfbf01552db093d81d63
<!-- The PR description should answer 2 important questions: -->
### What
Previously we stored scalar values for `OrderByExpression` inline, now
we break them out into their own discreet metadata items.
### How
Mostly fixing tests.
V3_GIT_ORIGIN_REV_ID: e3ee1c1c9c5ae05113cf82c10627cc89b8b9894c
<!-- The PR description should answer 2 important questions: -->
TODO:
- ~Add a test for parsing connection expiry from headers~
### What
<!-- What is this PR trying to accomplish (and why, if it's not
obvious)? -->
<!-- Consider: do we need to add a changelog entry? -->
<!-- Does this PR introduce new validation that might break old builds?
-->
<!-- Consider: do we need to put new checks behind a flag? -->
Expire the connection if the duration is set in the `Context`.
### How
Spawn a background thread to wait until the expiry. Send a close message
after waiting completes.
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
V3_GIT_ORIGIN_REV_ID: a9d06c57d75cc87abc3c470ee096a99a8f378a9a
<!-- The PR description should answer 2 important questions: -->
### What
Now when resolving `orderableRelationship` in `order_by_expressions` we
check the relationship name refers to a real relationship on that type,
and throw an error if not.
If we lookup the relationship and it refers to an unknown subgraph, we
exclude it but do not error.
V3_GIT_ORIGIN_REV_ID: 4d310c6e800cf830860efce30e28fc5f258bf39b
<!-- The PR description should answer 2 important questions: -->
### What
We want to change this error message
```json
{
"error": "error in data fusion: External error: Mutations are requested to be disallowed as part of the request"
}
```
to this
```json
{
"error": "error in data fusion: External error: Mutations are requested to be disallowed as part of the request",
"detail": {
"subgraph": "default",
"commandName": "uppercase_actor_name_by_id",
"arguments": {
"id": {
"literal": 1
}
}
}
}
```
<!-- What is this PR trying to accomplish (and why, if it's not
obvious)? -->
<!-- Consider: do we need to add a changelog entry? -->
<!-- Does this PR introduce new validation that might break old builds?
-->
<!-- Consider: do we need to put new checks behind a flag? -->
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
V3_GIT_ORIGIN_REV_ID: 5d1f712c039ac9a4685c480634f1e7e17ff94c4b
<!-- The PR description should answer 2 important questions: -->
### What
Float literals in SQL are represented as `Float64` values. We were check
for precision loss when converting these Float64 values into Float32
values. We now only check if there is an overflow.
<!-- Consider: do we need to add a changelog entry? -->
<!-- Does this PR introduce new validation that might break old builds?
-->
<!-- Consider: do we need to put new checks behind a flag? -->
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
V3_GIT_ORIGIN_REV_ID: 1630e6130591df19f16be7cc97bbc6515537d951
<!-- The PR description should answer 2 important questions: -->
### What
Before making the scalar order by expressions changes, adding a few more
introspection tests to the current thing so we can check we don't break
these.
V3_GIT_ORIGIN_REV_ID: d15efd3b98e2c058d77e443e5cc218034f3b3e6d
<!-- The PR description should answer 2 important questions: -->
### What
Adds response types for JSONAPI endpoints. They look OK!
<img width="733" alt="Screenshot 2024-10-23 at 17 48 05"
src="https://github.com/user-attachments/assets/cbd52523-3511-404a-9716-eed142847158">
V3_GIT_ORIGIN_REV_ID: 72050f3d0accf57c3c77e83aed4bd684da46786b
### What
If a connector defined a function/procedure/collection argument that
took a predicate type, but made it a nullable predicate type, then
metadata-resolve would fail to bind an argument preset for that argument
in ModelPermissions and CommandPermissions.
This has been fixed.
### How
The code that bound a boolean expression to the argument wasn't stepping
through nullable types properly. This has been fixed by reusing a
nullable type unwrapping function from another module (and moving it
into a shared location for reuse).
New metadata resolve tests have been added to verify that this works,
for both the nullable and non-nullable cases.
---------
Co-authored-by: Brandon Martin <brandon@codedmart.com>
V3_GIT_ORIGIN_REV_ID: 4d33d53522551a6217e618451041aa3b1cf89e52
<!-- The PR description should answer 2 important questions: -->
### What
<!-- What is this PR trying to accomplish (and why, if it's not
obvious)? -->
<!-- Consider: do we need to add a changelog entry? -->
<!-- Does this PR introduce new validation that might break old builds?
-->
<!-- Consider: do we need to put new checks behind a flag? -->
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
V3_GIT_ORIGIN_REV_ID: 894ba81666bb441e71b8e204b89e5732ac4f1c83
<!-- The PR description should answer 2 important questions: -->
### What
Some "medium-hanging" fruit optimizations of mbs validate and build code
paths
Latest timing relative to `main` as of 10/18:
```
validate example/chinook.json
time: [6.3984 ms 6.4236 ms 6.4532 ms]
change: [-46.276% -45.876% -45.440%] (p = 0.00 < 0.05)
Performance has improved.
validate example/multiple-subgraphs.json
time: [1.6909 ms 1.7024 ms 1.7165 ms]
change: [-44.488% -44.141% -43.771%] (p = 0.00 < 0.05)
Performance has improved.
validate example/chinook-invoices.json
time: [3.8878 ms 3.9039 ms 3.9220 ms]
change: [-45.544% -45.201% -44.863%] (p = 0.00 < 0.05)
Performance has improved.
validate example/big_pretty_DONT_COMMIT.json
time: [3.6692 s 3.6789 s 3.6889 s]
change: [-36.964% -36.755% -36.544%] (p = 0.00 < 0.05)
Performance has improved.
build example/chinook.json
time: [18.274 ms 18.345 ms 18.414 ms]
change: [-29.874% -29.359% -28.850%] (p = 0.00 < 0.05)
Performance has improved.
build example/multiple-subgraphs.json
time: [3.4423 ms 3.4588 ms 3.4760 ms]
change: [-33.073% -32.628% -32.199%] (p = 0.00 < 0.05)
Performance has improved.
build example/chinook-invoices.json
time: [11.000 ms 11.027 ms 11.057 ms]
change: [-26.051% -25.757% -25.449%] (p = 0.00 < 0.05)
Performance has improved.
Benchmarking build example/big_pretty_DONT_COMMIT.json: Collecting 100 samples in estimated 1359.8 s (100 iterations)
build example/big_pretty_DONT_COMMIT.json
time: [13.429 s 13.465 s 13.503 s]
change: [-21.864% -21.634% -21.367%] (p = 0.00 < 0.05)
Performance has improved.
```
### How
✨ optimizing ✨
### Internal details
The absolute numbers for build in the PR are not accurate after rebasing
on current `main`, but absolute improvement in secs/ms is about the
same.
(/private)
V3_GIT_ORIGIN_REV_ID: a4fe628a08a35a88c2ca958a1d22f1fc6ddf2a5b
### What
The supported NDC Spec was previously bumped to v0.1.6, but the
reference in the JSON Schema was not updated at the same time. This has
been corrected.
V3_GIT_ORIGIN_REV_ID: edbe31eafcd9fb72bdc457f38575d9e42931ecd0
### What
The warning about AuthConfig v1 being deprecated was only being
displayed in the engine's stdout logs and not as a build warning. This
has been corrected.
### How
Because AuthConfig is not part of OpenDD metadata, it is not handled
during metadata resolve. The existing warning printed from stdout is
printed during engine startup when it reads the AuthConfig. This is not
does not happen during the MBS build. So the warning logic is now called
during the MBS build so that a warning is emitted there too.
V3_GIT_ORIGIN_REV_ID: b4cf340597e3fad0603dd8c8d3e198f1867669eb
<!-- The PR description should answer 2 important questions: -->
### What
To generate JSONAPI OpenAPI spec we need to know the underlying type
representation of custom types. This is (optionally) provided by a data
connector in it's `scalar_types` section. It's really annoying to look
up, so let's collect them all and store them on the
`ScalarTypeRepresentation`, keyed by `Qualified<DataConnectorName>`.
No functional change, this will be used in JSONAPI OpenAPI generation
shortly.
V3_GIT_ORIGIN_REV_ID: 084304a580aca977e1f8c39b16938205a49b1b0e
### What
Previously, we only supported String as the type that contained your
session variable value when they are provided from webhooks/JWT/NoAuth.
We then coerced that value into whatever type was actually expected (eg
a float) later.
However, when we added support for array-typed session variables (#1221)
we didn't actually allow you to provide a JSON array of values as a
session variable value. You had to provide a string that contained a
JSON-encoded array of values. This meant that webhooks/JWT/NoAuth had to
double JSON-encode their session variables when returning them.
This PR fixes this and makes it so that webhooks/JWT/NoAuth can return
JSON values for session variables and that JSON is respected. So if a
session variable needs to be an array of integers, they can simply
return the JSON array of integers as the value for that session
variable.
### How
Instead of holding a `SessionVariableValue` as a `String`, we now turn
that into an enum where we have an "unparsed" String (used for when we
don't receive JSON, we just receive a string value (ie. http headers)),
or a "parsed" JSON value. When we receive session variables from
webhooks/JWT/NoAuth, we relax the restriction that they can only return
us JSON strings, and instead allow them to return JSON Values, which we
put in the new `SessionVariableValue::Parsed` enum variant. HTTP headers
go into `SessionVariableValue::Unparsed`.
Then, when we go to get the required value from the
`SessionVariableValue` based on the desired type, we either parse it out
of the "unparsed" String, or we expect that the value is already in the
correct form in the "parsed" JSON value. This is the behaviour you will
get if JSON session variables are turned on in the Flags.
If JSON session variables are not turned on, then we expect that only
String session variables (parsed or unparsed) are provided from
headers/webhooks/JWT/NoAuth, and so we run the old logic of always
expecting a String and parsing the correct value out of it.
V3_GIT_ORIGIN_REV_ID: b6734ad5443b7d68065f91aea71386c893aa7eba
<!-- The PR description should answer 2 important questions: -->
### What
<img width="731" alt="Screenshot 2024-10-17 at 16 39 07"
src="https://github.com/user-attachments/assets/a9e504e8-68f1-4c89-930d-2a5b00549dfc">
<img width="723" alt="Screenshot 2024-10-17 at 16 39 14"
src="https://github.com/user-attachments/assets/9bd76265-1726-4825-a25f-c4faac42990f">
This PR exposes a super basic OpenAPI 3.1 spec for the JSONAPI at
`/v1/rest/__schema`.
It includes:
- `page[limit]` and `page[offset]`
- `fields[ModelName]`
It does not include:
- `sorting`
- return types
- It also changes the JSONAPI to be served from `/v1/rest/` instead of
`/v1/jsonapi`.
The schema is generated depending on the user's role, so they'll only
see fields they'll allowed to.
### How
- Generate a `State` type for each `Role`
- Use `oas3` crate for types, manually create `Spec` type.
V3_GIT_ORIGIN_REV_ID: d15bb1dbc690795dcd3e2d8d245fd59e97653a56
<!-- The PR description should answer 2 important questions: -->
### What
<!-- What is this PR trying to accomplish (and why, if it's not
obvious)? -->
<!-- Consider: do we need to add a changelog entry? -->
<!-- Does this PR introduce new validation that might break old builds?
-->
<!-- Consider: do we need to put new checks behind a flag? -->
- Propagate baggage across span links and push websocket id into
baggage.
- Attach usage analytics attributes to execute span.
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
- First, move setting usage attributes into a separate function. Re-use
it in websockets code.
- Open a new `execute` span within the `websocket_execute_query` and
attach usage attributes to it.
- Add support to propagate trace baggage across span links. Push
websocket id into trace baggage.
- Remove setting `websocket.id` attribute in new linked traces as the
tracer will set websocket.id in baggage as an attribute.
V3_GIT_ORIGIN_REV_ID: 96338d8b9b3eb2f927e3ca57336e8372093ab585
I am sorry @rakeshkky , we will merge this again once we've done a
release, I promise.
Reverts hasura/v3-engine#1254
V3_GIT_ORIGIN_REV_ID: 74236d25d4e84658717531a55d87c8d3371b553c
<!-- The PR description should answer 2 important questions: -->
### What
<!-- What is this PR trying to accomplish (and why, if it's not
obvious)? -->
<!-- Consider: do we need to add a changelog entry? -->
<!-- Does this PR introduce new validation that might break old builds?
-->
<!-- Consider: do we need to put new checks behind a flag? -->
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
V3_GIT_ORIGIN_REV_ID: 3458ea1e5ebe2d7387a7e503f957e5d55f225599
<!-- The PR description should answer 2 important questions: -->
### What
This PR adds a check to disallow defining boolean expression of array
fields with scalar boolean type while resolving the boolean expression
`comparable_fields`.
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
V3_GIT_ORIGIN_REV_ID: e9fd2feaff5a20d05b51b9ccd2a460f2b7e767dc
