<!-- 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? -->
Until now the `allow_subscriptions` in select permission is no-op. This
PR implements its intended functionality, i.e, do not generate
subscription root field schema for models that don't have
`allow_subscriptions: true`.
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
- Plumb the `allow_subscriptions` value to namespace annotation.
- Modify subscription root field annotations; filter roles by
allow_subscriptions.
- Add a check in IR generation for the permission and raise an internal
error, if the check fails.
V3_GIT_ORIGIN_REV_ID: 98120809b1294716c96c190e1b6ec875635b5da1
<!-- The PR description should answer 2 important questions: -->
### What
Work so far has been mostly in one big file, let's split it up a bit so
we can see what is going on better.
### How
Move code around. No functional changes.
V3_GIT_ORIGIN_REV_ID: 7dbb2ea8d66de845a0e725edf61eede65cd2d994
<!-- The PR description should answer 2 important questions: -->
### What
This PR enables argument presets in the OpenDD pipeline by using
functions from `graphql_ir`. In the ideal future we'd flip the
dependency and move these functions out of `graphql_ir` and into the
`plan` crate, however we can't do that until `execute` crate is no
longer in active development as it will involve making a big mess there.
### How
- Calculate argument presets in the `plan/query/model_target` module
using functions from `graphql_ir`
- We also begin adding boolean expression resolve, then back away slowly
as it's a massive job and better tackled when we start making `where`
clauses work in this pipeline, to stop this PR ballooning insanely.
V3_GIT_ORIGIN_REV_ID: 47867452b7366e83f71b118e37302de93d9bde72
<!-- The PR description should answer 2 important questions: -->
Fixes
- offset / limit didn't work - fixed by updating the `hasura/jsonapi`
library to use `offset` / `limit` instead of `number` / `page` - this
was a change in JSONAPI 1.1
- Render type names as `subgraph_typename`
- Send `OrderBy` as `None` when it contains no columns - `Some(vec![])`
was upsetting Mongo, so let's be more stringent.
No functional changes as feature is behind flag.
V3_GIT_ORIGIN_REV_ID: 419993a3acd955ef74872078d11769f564c7fc36
<!-- 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? -->
The `example` JSON schema attribute can be specified multiple times
enabling inclusion of multiple examples. The OpenDd metadata is
auto-documented in hasura.io/docs using the json schema. Having multiple
examples is quite helpful for our users.
Inspired from the `schemars`'s `example` attribute behavior.
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
- Use `#[darling(multiple)]` attr to allow the `example` attribute
multiple times.
- Add more examples for model predicates and permission.
V3_GIT_ORIGIN_REV_ID: 7e9c31891afed5b96ec8a5bb7538062382ef4d27
<!-- The PR description should answer 2 important questions: -->
### What
We've been testing our OpenDD pipeline with snapshot tests that run for
each role. However, now that we're adding argument presets, it means
that the results will potentially be different. Therefore this saves
snapshots for each role the test is run against so that we don't get
tests conflicting with themselves. Functional no-op.
### How
Change label in `insta::assert_json_snapshot!`, commit new snapshots.
V3_GIT_ORIGIN_REV_ID: 1570ed82bdb76d27270c73c96d2671e8a3c7fe13
<!-- 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)? -->
---------
Co-authored-by: Abhinav Gupta <127770473+abhinav-hasura@users.noreply.github.com>
V3_GIT_ORIGIN_REV_ID: 05adb2015efda4d5244b93cfe337991370f0b27e
<!-- The PR description should answer 2 important questions: -->
### What
Previously we were doing the business of calculating which arguments
(and parts of arguments) were preset in the GraphQL `schema` crate. This
meant we would have to reimplement the logic for each backend. Now we
move it into `metadata-resolve` so the results can be shared by all
frontends.
### How
Move argument preset resolve into `metadata-resolve`. What's left in
`graphql-schema` is all the stuff relating to `Annotation`s of various
kinds.
A lot of the diff is changing `ModelWithPermissions` and
`CommandWithPermissions` to `ModelWithArgumentPresets` and
`CommandWithArgumentPresets` in crates after `metadata-resolve`.
Functional no-op.
V3_GIT_ORIGIN_REV_ID: b1b0983abb9f6282652c8689b02e0796026752f5
<!-- 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? -->
- Return the `Sec-WebSocket-Id` header denoting a unique id for the
websocket connection, in the handshake request response.
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
V3_GIT_ORIGIN_REV_ID: 3639a231e3bdcb8f1f6affa66c21254890dd9d2d
<!-- The PR description should answer 2 important questions: -->
### What
Make sure we trash old Postgres DB data when refreshing Docker, to make
sure we start with the newest data.
V3_GIT_ORIGIN_REV_ID: 25416e918431a915fece6fe2d9478fa722f6a7c5
Bumps [indexmap](https://github.com/indexmap-rs/indexmap) from 2.5.0 to
2.6.0.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/indexmap-rs/indexmap/blob/master/RELEASES.md">indexmap's
changelog</a>.</em></p>
<blockquote>
<h2>2.6.0 (2024-10-01)</h2>
<ul>
<li>Implemented <code>Clone</code> for <code>map::IntoIter</code> and
<code>set::IntoIter</code>.</li>
<li>Updated the <code>hashbrown</code> dependency to version 0.15.</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="bf0362ba25"><code>bf0362b</code></a>
Merge pull request <a
href="https://redirect.github.com/indexmap-rs/indexmap/issues/354">#354</a>
from cuviper/release-2.6.0</li>
<li><a
href="bd0b4f7c8c"><code>bd0b4f7</code></a>
Add all release dates</li>
<li><a
href="53400496f4"><code>5340049</code></a>
Release 2.6.0</li>
<li><a
href="7f8022912a"><code>7f80229</code></a>
Merge pull request <a
href="https://redirect.github.com/indexmap-rs/indexmap/issues/343">#343</a>
from cuviper/hash_table</li>
<li><a
href="e577bf2556"><code>e577bf2</code></a>
Use <code>hashbrown::HashTable</code> instead of
<code>RawTable</code></li>
<li><a
href="09b48ec3b3"><code>09b48ec</code></a>
Merge pull request <a
href="https://redirect.github.com/indexmap-rs/indexmap/issues/353">#353</a>
from cuviper/move_index</li>
<li><a
href="267b83d701"><code>267b83d</code></a>
Add an explicit bounds check in <code>move_index</code></li>
<li><a
href="d74a4daffb"><code>d74a4da</code></a>
Merge pull request <a
href="https://redirect.github.com/indexmap-rs/indexmap/issues/349">#349</a>
from waywardmonkeys/improve-doc-formatting</li>
<li><a
href="5b0ed20b87"><code>5b0ed20</code></a>
docs: Improve doc formatting with backticks</li>
<li><a
href="15518f3152"><code>15518f3</code></a>
Merge pull request <a
href="https://redirect.github.com/indexmap-rs/indexmap/issues/348">#348</a>
from cuviper/clone-intoiter</li>
<li>Additional commits viewable in <a
href="https://github.com/indexmap-rs/indexmap/compare/2.5.0...2.6.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>
V3_GIT_ORIGIN_REV_ID: cee54b0b6eba5ce1f1c7327be81162ac96d54b1c
Bumps [serde_with](https://github.com/jonasbb/serde_with) from 3.9.0 to
3.11.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/jonasbb/serde_with/releases">serde_with's
releases</a>.</em></p>
<blockquote>
<h2>serde_with v3.11.0</h2>
<h3>Added</h3>
<ul>
<li>
<p>Add support for <code>hashbrown</code> v0.15 (<a
href="https://redirect.github.com/jonasbb/serde_with/issues/787">#787</a>/<a
href="https://redirect.github.com/jonasbb/serde_with/issues/790">#790</a>)</p>
<p>This extends the existing support for <code>hashbrown</code> v0.14 to
the newly released version.</p>
</li>
</ul>
<h2>serde_with v3.10.0</h2>
<h3>Added</h3>
<ul>
<li>
<p>Add newline separator by <a
href="https://github.com/jayvdb"><code>@jayvdb</code></a> (<a
href="https://redirect.github.com/jonasbb/serde_with/issues/777">#777</a>)</p>
<p>The <code>UnixLineSeparator</code> and <code>DosLineSeparator</code>
can be used together with <code>StringWithSeparator</code>.</p>
</li>
</ul>
<h3>Fixed</h3>
<ul>
<li>
<p>Proper handling of <code>cfg_attr</code> in the <code>serde_as</code>
macro by <a
href="https://github.com/sivizius"><code>@sivizius</code></a> (<a
href="https://redirect.github.com/jonasbb/serde_with/issues/782">#782</a>)</p>
<p>This allows to parse more valid forms of the <code>cfg_attr</code>
macro, including multiple values and attribute that do not follow the
<code>key = value</code> schema.</p>
</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="bc2063440d"><code>bc20634</code></a>
Bump version to 3.11 (<a
href="https://redirect.github.com/jonasbb/serde_with/issues/791">#791</a>)</li>
<li><a
href="bf8cfd48a2"><code>bf8cfd4</code></a>
Bump version to 3.11</li>
<li><a
href="a58cb33e4f"><code>a58cb33</code></a>
Add support for hashbrown v0.15 (<a
href="https://redirect.github.com/jonasbb/serde_with/issues/790">#790</a>)</li>
<li><a
href="ef7403d394"><code>ef7403d</code></a>
Update changelog</li>
<li><a
href="5d97c6a349"><code>5d97c6a</code></a>
Add support for hashbrown v0.15</li>
<li><a
href="db290afa3a"><code>db290af</code></a>
Bump regex from 1.10.3 to 1.11.0 (<a
href="https://redirect.github.com/jonasbb/serde_with/issues/788">#788</a>)</li>
<li><a
href="a329a52ac3"><code>a329a52</code></a>
Bump regex from 1.10.3 to 1.11.0</li>
<li><a
href="eb417640dc"><code>eb41764</code></a>
Fix clippy::needless_lifetimes (<a
href="https://redirect.github.com/jonasbb/serde_with/issues/789">#789</a>)</li>
<li><a
href="eca5a271af"><code>eca5a27</code></a>
Fix clippy::needless_lifetimes</li>
<li><a
href="f1b79f27ca"><code>f1b79f2</code></a>
Bump version to 3.10.0 (<a
href="https://redirect.github.com/jonasbb/serde_with/issues/786">#786</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/jonasbb/serde_with/compare/v3.9.0...v3.11.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>
V3_GIT_ORIGIN_REV_ID: bb5afa736a4579d2c83c5fbad8096254c0666a01
Bumps [clap](https://github.com/clap-rs/clap) from 4.5.18 to 4.5.19.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/clap-rs/clap/releases">clap's
releases</a>.</em></p>
<blockquote>
<h2>v4.5.19</h2>
<h2>[4.5.19] - 2024-10-01</h2>
<h3>Internal</h3>
<ul>
<li>Update dependencies</li>
</ul>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/clap-rs/clap/blob/master/CHANGELOG.md">clap's
changelog</a>.</em></p>
<blockquote>
<h2>[4.5.19] - 2024-10-01</h2>
<h3>Internal</h3>
<ul>
<li>Update dependencies</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="108907385c"><code>1089073</code></a>
chore: Release</li>
<li><a
href="c9b8c85f09"><code>c9b8c85</code></a>
docs: Update changelog</li>
<li><a
href="8b3de18a8d"><code>8b3de18</code></a>
Merge pull request <a
href="https://redirect.github.com/clap-rs/clap/issues/5685">#5685</a>
from epage/engine</li>
<li><a
href="b38538d7c4"><code>b38538d</code></a>
fix(complete)!: Rename dynamic to engine</li>
<li><a
href="232af62f7d"><code>232af62</code></a>
Merge pull request <a
href="https://redirect.github.com/clap-rs/clap/issues/5684">#5684</a>
from epage/endless</li>
<li><a
href="0209a79031"><code>0209a79</code></a>
fix(complete): Don't cause endless completions for bash/zsh</li>
<li>See full diff in <a
href="https://github.com/clap-rs/clap/compare/clap_complete-v4.5.18...clap_complete-v4.5.19">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>
V3_GIT_ORIGIN_REV_ID: 764e2671ba2986148086b31ee644295623a6d7f7
Bumps [tokio-tungstenite](https://github.com/snapview/tokio-tungstenite)
from 0.20.1 to 0.24.0.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/snapview/tokio-tungstenite/blob/master/CHANGELOG.md">tokio-tungstenite's
changelog</a>.</em></p>
<blockquote>
<h1>0.24.0</h1>
<ul>
<li>Update dependencies (TLS, tungstenite).</li>
<li>Return a runtime error when WSS URLs are used without a proper TLS
feature enabled.</li>
</ul>
<h1>0.23.1</h1>
<ul>
<li>Introduce a <code>url</code> feature (proxies to
<code>tungstenite/url</code>).</li>
</ul>
<h1>0.23.0</h1>
<ul>
<li>Update <code>tungstenite</code> to <code>0.23.0</code>.</li>
<li>Disable default features on TLS crates.</li>
</ul>
<h1>0.22.0</h1>
<ul>
<li>Update TLS dependencies.</li>
<li><del>Update <code>tungstenite</code> to match
<code>0.22.0</code>.</del></li>
</ul>
<h1>0.21.0</h1>
<ul>
<li>Update TLS dependencies.</li>
<li>Update <code>tungstenite</code> to <code>0.21.0</code>.</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="cae2e89102"><code>cae2e89</code></a>
Bump version -> 0.24.0</li>
<li><a
href="0b9d97bc14"><code>0b9d97b</code></a>
deps: update <code>rustls-native-certs</code> to 0.8 (<a
href="https://redirect.github.com/snapview/tokio-tungstenite/issues/348">#348</a>)</li>
<li><a
href="94a35a0d6b"><code>94a35a0</code></a>
Additional Documentation of <code>IntoClientRequest</code> on
<code>connect_async</code> (<a
href="https://redirect.github.com/snapview/tokio-tungstenite/issues/342">#342</a>)</li>
<li><a
href="83258250c2"><code>8325825</code></a>
Prepare 0.23.1 release</li>
<li><a
href="db9ae7eb71"><code>db9ae7e</code></a>
Re-introduce the <code>url</code> feature</li>
<li><a
href="a53454b16d"><code>a53454b</code></a>
Prepare 0.23.0 release</li>
<li><a
href="c1025d59ff"><code>c1025d5</code></a>
Disable rustls default features</li>
<li><a
href="ff311384b6"><code>ff31138</code></a>
Prepare 0.22.0 release</li>
<li><a
href="ad1d511a30"><code>ad1d511</code></a>
Update <code>rustls</code> to 0.23 and <code>tokio-rustls</code> to
0.26</li>
<li><a
href="052d085aff"><code>052d085</code></a>
Simplify response body type in <code>server-custom-accept</code>
example</li>
<li>Additional commits viewable in <a
href="https://github.com/snapview/tokio-tungstenite/compare/v0.20.1...v0.24.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>
V3_GIT_ORIGIN_REV_ID: aecbec51ea7eb1a46debda1f081aa913d093018e
<!-- The PR description should answer 2 important questions: -->
### What
This PR enables queries `__typename` introspection field in aggregate
queries.
This PR also adds a test for the same.
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
We have changed how we handle __typename while processing the selection
set. If you use `as_object_selection_set`, you will get `__typename` for
free.
We are going to follow the same pattern as in the non-aggregate fields.
The following has changed:
- While generating the IR, we will ignore introspection fields.
- use `as_object_selection_set` to process the selection set.
V3_GIT_ORIGIN_REV_ID: 0b88d497efd9b754483dd786fe7e8ef5fcb462f1
<!-- 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? -->
We can change a few `Skip` to `TestNDCResponses` or
`GenerateOpenDDQuery`.
We are still skipping tests for the following features:
- introspection
- order_by relationship
- where relationship
- where remote_relationship
- relay
- commands procedures
- field presets
- relationship predicates
- remote_relationship predicates
- apollo_federation
- aggregates
- most of the relationship tests
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
V3_GIT_ORIGIN_REV_ID: ea0a5d865cc40f8f7428d8e742f48dc6be300696
<!-- The PR description should answer 2 important questions: -->
### What
This PR adds two new operand types for `BooleanExpressionType` in
OpenDD: `objectAggregate` and `scalarAggregate`. These two operand types
are then validated in metadata resolve to ensure their correctness.
Their design is based on [this
RFC](https://github.com/hasura/v3-engine/pull/945#issuecomment-2325652794).
They are hidden from the OpenDD JSON Schema and their usage is blocked
by default via a new unstable feature flag.
They are also currently not "usable", as the metadata resolve code that
would use an `objectAggregate` operand-ed `BooleanExpressionType` to
satisfy an aggregate predicate over an array relationship does not
exist. This will be added in a future PR; this PR is big enough!
### How
A new unstable feature `enable_aggregation_predicates` has been added to
gate this feature behind while it is in development.
The new OpenDD types have been added to
`crates/open-dds/src/boolean_expression.rs`.
A new metadata resolve stage `aggregate_boolean_expressions` has been
added that specifically resolves these two new operand types. Most of
the new code changes in this PR exist in this new stage.
The output of this stage is composed into the `boolean_expressions`
stage afterwards, but other than just being consumed and included there,
it is unused for now. In a future PR it will be used when resolving
object-operanded `BooleanExpressionTypes`.
An exhaustive set of metadata resolve tests has been added to test all
the error, warning and passing cases for both object and scalar
aggregate operands
(`crates/metadata-resolve/tests/failing/aggregate_boolean_expressions/`
and
`crates/metadata-resolve/tests/passing/aggregate_boolean_expressions/`).
These files make up the vast majority of the file count in this PR.
V3_GIT_ORIGIN_REV_ID: e0e030b322d05212a0e2630acc9f4db7b05000c1
<!-- 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? -->
Essential artifacts, like schema and auth/plugin configs, required for a
websocket connection are cloned on each request. This is causing massive
memory spike while simulating 10k concurrent connections using
graphql-bench tool.
My machine has 62GB of ram, so absolute usage is `30% of 62G ~ 18 GB`.
I spent some time debugging dangling tokio tasks from closed websockets
using [tokio_console](https://github.com/tokio-rs/console). Tokio tasks
are closed as expected when websockets are dropped.
I gone through the graphql-ws code line-by-line and found that we are
cloning the schema for each websocket connection. The reason for this is
that, initially, I couldn't find a way to generate an `Arc` for just the
schema from the EngineState struct. ~However, I found a solution by
using the
[mappable-rc](https://docs.rs/mappable-rc/latest/mappable_rc/index.html)
crate.~ Tweak the `EngineState` struct to hold heavy fields inside `Arc`
to pass them around separately. Just pass the `EngineState` without
wrapping in `Arc` across axum routes, as it is cheap to clone now.
After wrapping all artifact values with `Arc`, the memory usage
decreased drastically.
The screenshot above shows 1% memory usage for 10,000 concurrent
connections. From multiple runs, I found the average usage to be around
1.2% - 1.4%, which roughly translates to ~ `800MB`.
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
- Avoid cloning schema, auth_config and plugin artifacts on a new
websocket connections. Now, `EngineState` contains these values wrapped
with `Arc`. Use them directly.
- Refactor other parts of code to accommodate the above changes.
V3_GIT_ORIGIN_REV_ID: f56a9eecf6e9eca9fdc56bf332f9a06f5ad4cdb5
### What
Like #1192, this PR adds a context to another error raised during the
`models` resolution step. Specifically, `UnknownModelCollection`.
### How
These PRs are extremely simple, it's just that there are going to be
dozens of them. When an error refers to a thing, you wrap that thing in
`Spanned`, and then try to extract the `path` at the error site. Most of
the time, it's pretty straightforward.
---------
Co-authored-by: Daniel Chambers <daniel@hasura.io>
V3_GIT_ORIGIN_REV_ID: d3ea71d3d9a42cbf804add54f5f6e75ab68c6765
### What
Currently if you want v3-engine to accept metadata that is only a
partial supergraph (ie missing some subgraphs), you must set the
PARTIAL_SUPERGRAPH env var. Builds sent to MBS get sent to a special
endpoints `/validate/partial` and `/build/partial` that runs the engine
build process with that configuration option set.
This results in a terrible user experience for local builds, because MBS
will accept a partial supergraph and yield build artifacts, but
v3-engine will refuse to run them unless you set that env var.
This PR removes that env var and creates a new OpenDD flag called
`allow_partial_supergraph`. When MBS's `/validate/partial` endpoint is
used, that flag is set in the build artifacts. v3-engine then looks at
that flag to enable partial supergraph mode. This means a
`/build/partial` build via MBS just works when you run it locally via
v3-engine.
### How
`metadata_resolve`'s `Configuration.allow_unknown_subgraphs` has been
removed, and `metadata_resolve` now looks at OpenDD's new
`Flags.allow_partial_supergraph` instead.
In MBS, usage of `ValidationMode` (the enum that enables partial builds)
previously used to set `Configuration.allow_unknown_subgraphs`; now it
is used in `compute_open_dds_flags` in order to set
`Flags.allow_partial_supergraph`.
The existing metadata_resolve test that tested partial supergraphs has
been modified to use the flags rather than the removed configuration
option
(`crates/metadata-resolve/tests/passing/missing_subgraph_when_ignoring_unknown_subgraphs`).
A new `metadata_resolve` test has been added that checks that comparable
relationships in `BooleanExpressionType` properly respects the
`allow_partial_subgraphs` flag (this functionality was added in #1182).
V3_GIT_ORIGIN_REV_ID: 2c984eb791263a1fb0606c6c44a2a1ae4a5e7370
<!-- The PR description should answer 2 important questions: -->
### What
Set us up for more visibility into performance on prod.
### How
Add traces
V3_GIT_ORIGIN_REV_ID: 0ea011c1233a08bf4f9d55a9084809a6ffcd934d
<!-- The PR description should answer 2 important questions: -->
### What
Functional no-op towards making `graphql_ir` less central and breaking
some import cycles.
### How
Move the function.
V3_GIT_ORIGIN_REV_ID: 53ea007964f5ab79cb546821cfb76f542ea3b486
<!-- 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? -->
Execute configured pre-parse and pre-response plugins for GraphQL
operations over websockets.
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
When a `type: subscribe` message is received, similar to HTTP requests,
run pre-parse plugins. If the plugins' response results in "continue",
then proceed with handling the GraphQL query. Otherwise, return the
plugin response or error.
For pre-response plugins, a task is spawned for handling plugins before
sending the response to the client. The task is run in a new trace,
linked to the poll trace.
V3_GIT_ORIGIN_REV_ID: ceb7ffd6da9235b3897ef4198729c07492c13d5e
<!-- The PR description should answer 2 important questions: -->
### What
A lot of the `graphql_ir` is generally useful and not GraphQL specific.
Before we can move it into `plan` and share it we need to pull a few
shared types out of the package and somewhere more general too.
### How
Functional no-op.
V3_GIT_ORIGIN_REV_ID: 3fe8ca737ef3d8c7ce09ea695453645e303d7030
Since these might be 10s or even 100s of MB this is important for saving
bandwidth
<!-- The PR description should answer 2 important questions: -->
### What
Save bandwidth (and possibly latency, etc) in mbs
### How
Support compressed request bodies. When this is deployed clients like
ddn-api can use it.
V3_GIT_ORIGIN_REV_ID: ad6357880d7c81ad58a76a3edfbac8d377ad7f5c
<!-- The PR description should answer 2 important questions: -->
### What
Parse offset/limit in the GraphQL -> OpenDD pipeline, and use it test
offset / limit. Functional no-op.
V3_GIT_ORIGIN_REV_ID: 068d14d08a4bde140f5633625a59137d3ff81d84
<!-- 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? -->
Earlier, for pre-response plugins, a span is emitted for each plugin
execution. This PR wraps all plugin executions in a new span that
extends the client headers as parent context.
Before:
After:
Note: `pre_response_plugins_execute` span name renamed to
`execute_all_pre_response_plugins` in later commits.
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
Move execution of pre-response plugins in a task, into a new function.
Create a span that wraps a function that executes all plugins async.
V3_GIT_ORIGIN_REV_ID: a1febecf4b429e1441e4b53a9b32f39519a12ba9
<!-- The PR description should answer 2 important questions: -->
### What
Move the function/procedure planning from `sql` to the shared OpenDD IR
pipeline in `plan`. This should be a no-op for `sql`
### How
Move code, fix type errors.
V3_GIT_ORIGIN_REV_ID: 7da797ffedbc40a44692670679aa176817f2c65e
<!-- The PR description should answer 2 important questions: -->
### What
We need to bump `tonic` because of `cargo audit`, and to do so we need
to bump OpenTelemetry, and to do that we need to finally bump `http`,
and to do that...
### How
Follow the breadcrumb trail, fix the errors.
Checked, trace propagation still works:
<img width="1781" alt="Screenshot 2024-10-02 at 15 56 28"
src="https://github.com/user-attachments/assets/4c3f8763-e646-445d-84de-f507da15ad2e">
V3_GIT_ORIGIN_REV_ID: aa219e91375aa310dc656183948edc33f77cdfdc
<!-- 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? -->
Write tests to confirm websocket connection behavior in conjunction with
[graphl-ws](https://github.com/enisdenjo/graphql-ws/blob/master/PROTOCOL.md)
subprotocol.
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
Test the websocket by spinning up a server in an async tokio task. Use
tokio-tungstenite for websocket client.
V3_GIT_ORIGIN_REV_ID: 32c19298b6a5b23649b22d8d820ef8d47ef1d293
<!-- The PR description should answer 2 important questions: -->
### What
Running `docker compose up` is a generally accepted way to try a project
out, and ours was broken.
This fixes ours so that running `docker compose up` builds engine and
runs it with a sample schema for `ndc-postgres`. This will allow users
to get a flavour for DDN as a consumer.
We also remove a bunch of outdated and frankly confusing stuff from the
readme, instead directing users to the docs.
V3_GIT_ORIGIN_REV_ID: 77c817d1738efafe4027c7d0da1aa21bcf78dd9d
<!-- The PR description should answer 2 important questions: -->
### What
Release `v2024-10-02`, let's do `v2024-10-02` instead.
### How
Update changelog.
V3_GIT_ORIGIN_REV_ID: a6fe7e0c81ea2d4b9cfe76322ee2586cd152b458
<!-- The PR description should answer 2 important questions: -->
### What
Previously when we used a string from a session variable as a passed
through header it would become double escaped like `\"the string\"`.
This is because we were encoding to JSON, going back to
`reqwest::header::HeaderValue` and then back to JSON. Instead, let's
stay in JSON.
### How
Instead we stay in JSON for the session variable encoding, and
explicitly do the `reqwest::header::HeaderValue` -> JSON encoding. We
take the string in `HeaderValue` and make it a
`serde_json::Value::String`.
V3_GIT_ORIGIN_REV_ID: 3fd4df7c4aac5eadedd2d533cdf8e20dfa718060
<!-- The PR description should answer 2 important questions: -->
### What
In #1168 we checked for duplicate command names. However this made a
project build fail, so we instead put this behind a flag and raise a
warning.
V3_GIT_ORIGIN_REV_ID: 41e3dcfda1d3f2da1e7ca672c9d20e0a3917d868
### What
This PR allows MBS errors to provide a larger "context". Our notion of
context is an ordered list of annotated paths. An example would be for a
name conflict, where we want to say `["this name was used here", "...
and also here"]`, so reporting two paths would be helpful.
Note that the actual format of `path` is a structured data type, not a
string. An example of the first instance introduced by this PR can be
seen here:
```json
{
"errors": [
{
"context": [
{
"message": "Data connector name given here",
"path": [
{ "Index": 11 },
{ "Key": "definition" },
{ "Key": "source" },
{ "Key": "dataConnectorName" }
]
}
],
"code": "opendds-validation",
"message": "invalid metadata: error building schema: invalid metadata: the source data connector b (in subgraph default) for model Artists (in subgraph default) has not been defined",
"path": null
}
]
}
```
The `path` key is already generated by other parts of the MBS process,
so we preserve it for now to avoid breaking changes.
### How
* A new crate, `error-context`, to hold the type of the context
structure.
* Otherwise essentially the same as the path mechanism.
V3_GIT_ORIGIN_REV_ID: 0bb529542ba0a7f6774c08fa6adb7d7c608d6c5b
<!-- The PR description should answer 2 important questions: -->
### What
Update changelog.
V3_GIT_ORIGIN_REV_ID: 5fd36aafebbad8321fb7ab95f8a7e46759441926
### What
This PR completes step 2 on the plan in #1153. With this PR, an attempt
to call MBS to build metadata containing a model referencing an unknown
data connector should result in a path to the model.
### How
#1179 introduced the polymorphic version of the error type introduced by
#1170. Unfortunately, due to Rust not having an apartness constraint, we
can't write `impl<T, S: From<T> From<WithContext<T>> for
WithContext<S>`, so we introduce the `coerce` function to allow us to
cast between `WithContext<ChildError>` and `WithContext<ParentError>`.
This means that we can return a `WithContext<ModelsError>` from the
models stage, coerce it to a `WithContext<Error>`, and propagate that
path throughout the system. This PR also extends the `path` function
inside MBS to detect these paths if present, so MBS API errors will
contain any available path.
V3_GIT_ORIGIN_REV_ID: a47c565b792fefb99294c9e21ba526424ddf7cb7
<!-- The PR description should answer 2 important questions: -->
### What
We used the old `source` key alias in doc examples, but we'd like to use
the newer `sourceType` instead.
### How
Change JSON example.
V3_GIT_ORIGIN_REV_ID: f3223fb9716a2cf277ea2e82891ae8bbcdcd9ee0
<!-- The PR description should answer 2 important questions: -->
### What
This PR makes the spans visible to the users.
### How
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
V3_GIT_ORIGIN_REV_ID: b39cc2496053f4eadaec2a260146c83e4ed5b24d
<!-- 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? -->
Create a new trace for each subscription poll and link the span. It is
done to avoid accumulation of polling spans in one trace. Also, move
waiting for poll interval to post execution.
### How
- Update `in_span_async_with_link` to `new_trace_async_with_link` which
signifies opening a new trace with a link.
- Wrap the body present `loop {}` in `new_trace_async_with_link` to emit
new trace for each poll.
- Capture poll exceptions in the trace.
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
V3_GIT_ORIGIN_REV_ID: c984ef70e0e55a5edae12e3f3c0580a0065516cd
### What
When the engine is run in `PARTIAL_SUPERGRAPH` mode, any relationship
that targets an unknown subgraph should be silently dropped. This was
being done when resolving relationship navigation fields on the
`ObjectType`, but not for `comparableRelationships` on
`BooleanExpressionType`. In that case we were erroring as we tried to
resolve the relationship and couldn't find the target subgraph.
### How
The `relationships` metadata resolve step has been enhanced to capture
if a relationship is targeting an unknown subgraph. The
`object_boolean_expressions` step already used this, so it was tweaked
to skip relationships targeting unknown subgraphs.
The `object_relationships` step, however, did not use `relationships`
and instead went back to metadata_accessor for relationships. It then
had special logic that skipped unknown subgraph relationships. The step
has now been refactored to use `relationships` instead and the special
skipping logic has been discarded, and it now just uses the unknown
subgraph information from `relationships`.
In addition, the `object_relationships` step now _consumes_ the output
of the `type_permissions` step, rather than cloning it. This reduces
unnecessary cloning and makes sense since `object_relationships` is
simply a further enriched version of `type_permissions`.
The test of whether the source object type of a relationship actually
exists has also been moved from `object_relationships` to
`relationships`, and the index built by `relationships` has been
reordered to group by type first and then name, since that is more
useful, especially in the `object_relationships` step.
V3_GIT_ORIGIN_REV_ID: e5d18343f5ce24532a3258e88751bc3183692c50
<!-- The PR description should answer 2 important questions: -->
### What
Fixes:
https://linear.app/hasura/issue/ENG-1073/figure-out-whats-causing-the-slowdown-in-response-processing
This removes the accidentally-quadratic behavior of repeated
nested `from_value`/`to_value` calls where the assumption seems to have
been
that ndc model fields containing Value would be untouched (similar to
the behavior of aeson).
### How
We work with `Value` directly instead of using `serde` machinery to get
a `RowSet`.
#### Benchmarks
The large result query shows modest latency improvement:
A query with a response of the same size as above, but with deep nesting
to trigger quadratic behavior shows significant latency improvement
(~12ms to ~2ms for `process_response` span)
Small responses (common, historically) don't show any improvement, as
they don't exhibit the issue.
V3_GIT_ORIGIN_REV_ID: f709e4f8a370b46c53f533eef2fef7e772b5cb72
### What
To do this iteratively, we want to be able to make e.g. models throw
contextualised errors while other stages don't. To do this, we want to
update the models code to return its own version of `ErrorWithContext`
with its own logic for propagating paths. To avoid the mess, I've made
this polymorphic.
V3_GIT_ORIGIN_REV_ID: 8ff2082e3ac8eea908727cffac93fd9cf58ddcce
<!-- 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? -->
Add traces to `graphql-ws` crate. Since websockets are implemented by
running multiple parallel tasks, we are using span links to establish
relation between traces emitted by those tasks.
Refactor by moving code into new modules and updating function names and
types.
### How
- Define a new `in_span_async_with_link()` in tracing-util to enable
creating a span with a link.
- Wrap spans around necessary code sections with attaching required
attributes.
- Small no-op refactor in `common.rs` test file.
<!-- How is it trying to accomplish it (what are the implementation
steps)? -->
V3_GIT_ORIGIN_REV_ID: 33cd313b94421097f3c1bb1bcf165f04c1a9cd65
<!-- The PR description should answer 2 important questions: -->
### What
Add basic NDC execution testing for the new pipeline to the existing
`engine/tests/execution.rs` tests. Grabs rows from NDC and snapshots the
results, but good enough to eyeball and see things are somewhat working.
Somewhat interesting: we can't test `selectUnique` queries using the new
pipeline, because the primary key argument isn't an actual model
argument (and thus fails in the `argument_mappings` lookup). It's
actually taken as an argument in GraphQL, but turned into an additional
filter expression and `AND`ed onto whatever filters are there. Will need
to have a think about this, but not now.
Functional no-op.
### How
Copy the execution step from JSONAPI and use it in engine tests.
V3_GIT_ORIGIN_REV_ID: 5b1ea8c1f08048b563db694b618c8823e4139383
<!-- The PR description should answer 2 important questions: -->
### What
Another incremental step towards metadata-resolve paths. This PR wraps
the current error type with `ErrorWithContext`, a type that can
optionally contain a path. The PR should be a functional no-op as we
still ignore these paths when displaying the error; the next PR will
surface them in the error responses.
### How
We wrap the type and then do a _lot_ of hand-holding to get Rust
inference to work.
V3_GIT_ORIGIN_REV_ID: c1384cb1e8700c9b7e3aa643b7d0fbd4c8471098
<!-- The PR description should answer 2 important questions: -->
### What
Before we pull the command planning into `plan`, let's split the types
so the general and DataFusion stuff don't live in the same place.
### How
Move types, follow errors. Functional no-op.
V3_GIT_ORIGIN_REV_ID: bb4adbc6897a79f47be37d5ad1a13b7b8efb5e93
<!-- The PR description should answer 2 important questions: -->
### What
A JSONAPI request allows users to provide the fields they require like
so:
```
fields[Authors]=author_id,first_name
```
This PR implements the most basic form of this, along with some notes on
what the better version could be. This is motivated by allowing us to
test the OpenDD pipeline more than anything else.
### How
Loop through sparse field sets looking for the field we want to include,
reject it if not.
JSONAPI is behind a feature flag so is a functional no-op.
V3_GIT_ORIGIN_REV_ID: 27dbb6103c42910be71529351e7a2c9ce0abcb4a
