graphql-engine/v3/crates/metadata-resolve/tests/metadata_golden_tests.rs

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

70 lines
2.3 KiB
Rust
Raw Normal View History

Allow supergraph config to appear in subgraphs (#611) ## Description As per [APG-113](https://hasurahq.atlassian.net/browse/APG-113), we would like to remove the separate concept of supergraphs. This is the first step: we allow the supergraph config to appear in subgraphs. The next step will be to remove the non-subgraph version of it. This PR updates the subgraph enum type to allow for supergraph config objects, but does nothing else. This means it should be a no-op for current users, but will be forward-compatible with the eventual goal of the epic. We also throw in a makeshift test framework that we can probably replace with Insta at a later date. <!-- Questions to consider answering: 1. What user-facing changes are being made? 2. What are issues related to this PR? (Consider adding `(close #<issue-no>)` to the PR title) 3. What is the conceptual design behind this PR? 4. How can this PR be tested/verified? 5. Does the PR have limitations? 6. Does the PR introduce breaking changes? --> ## Changelog - Add a changelog entry (in the "Changelog entry" section below) if the changes in this PR have any user-facing impact. See [changelog guide](https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide). - If no changelog is required ignore/remove this section and add a `no-changelog-required` label to the PR. ### Product _(Select all products this will be available in)_ - [x] community-edition - [x] cloud <!-- product : end : DO NOT REMOVE --> ### Type <!-- See changelog structure: https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog --> _(Select only one. In case of multiple, choose the most appropriate)_ - [ ] highlight - [ ] enhancement - [ ] bugfix - [x] behaviour-change - [ ] performance-enhancement - [ ] security-fix <!-- type : end : DO NOT REMOVE --> ### Changelog entry <!-- - Add a user understandable changelog entry - Include all details needed to understand the change. Try including links to docs or issues if relevant - For Highlights start with a H4 heading (#### <entry title>) - Get the changelog entry reviewed by your team --> Supergraph configuration (`CompatibilityConfig`, `AuthConfig`, and `GraphqlConfig`) may now be defined in any subgraph. Note that supergraph configuration may still only be defined once for any given supergraph. <!-- changelog-entry : end : DO NOT REMOVE --> <!-- changelog : end : DO NOT REMOVE --> [APG-113]: https://hasurahq.atlassian.net/browse/APG-113?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ V3_GIT_ORIGIN_REV_ID: a1b9911c4abb332fe37914efd1c3afbbd554a5d0
2024-05-24 11:59:03 +03:00
//! Tests that attempt to resolve different metadata files and assert that they parse successfully
//! or fail in the expected way.
use std::fs;
use std::path::PathBuf;
Allow supergraph config to appear in subgraphs (#611) ## Description As per [APG-113](https://hasurahq.atlassian.net/browse/APG-113), we would like to remove the separate concept of supergraphs. This is the first step: we allow the supergraph config to appear in subgraphs. The next step will be to remove the non-subgraph version of it. This PR updates the subgraph enum type to allow for supergraph config objects, but does nothing else. This means it should be a no-op for current users, but will be forward-compatible with the eventual goal of the epic. We also throw in a makeshift test framework that we can probably replace with Insta at a later date. <!-- Questions to consider answering: 1. What user-facing changes are being made? 2. What are issues related to this PR? (Consider adding `(close #<issue-no>)` to the PR title) 3. What is the conceptual design behind this PR? 4. How can this PR be tested/verified? 5. Does the PR have limitations? 6. Does the PR introduce breaking changes? --> ## Changelog - Add a changelog entry (in the "Changelog entry" section below) if the changes in this PR have any user-facing impact. See [changelog guide](https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide). - If no changelog is required ignore/remove this section and add a `no-changelog-required` label to the PR. ### Product _(Select all products this will be available in)_ - [x] community-edition - [x] cloud <!-- product : end : DO NOT REMOVE --> ### Type <!-- See changelog structure: https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog --> _(Select only one. In case of multiple, choose the most appropriate)_ - [ ] highlight - [ ] enhancement - [ ] bugfix - [x] behaviour-change - [ ] performance-enhancement - [ ] security-fix <!-- type : end : DO NOT REMOVE --> ### Changelog entry <!-- - Add a user understandable changelog entry - Include all details needed to understand the change. Try including links to docs or issues if relevant - For Highlights start with a H4 heading (#### <entry title>) - Get the changelog entry reviewed by your team --> Supergraph configuration (`CompatibilityConfig`, `AuthConfig`, and `GraphqlConfig`) may now be defined in any subgraph. Note that supergraph configuration may still only be defined once for any given supergraph. <!-- changelog-entry : end : DO NOT REMOVE --> <!-- changelog : end : DO NOT REMOVE --> [APG-113]: https://hasurahq.atlassian.net/browse/APG-113?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ V3_GIT_ORIGIN_REV_ID: a1b9911c4abb332fe37914efd1c3afbbd554a5d0
2024-05-24 11:59:03 +03:00
use metadata_resolve::MetadataResolveFlagsInternal;
#[test_each::file(
glob = "crates/metadata-resolve/tests/passing/**/metadata.json",
Metadata resolve for aggregates over relationships (#731) ## Description This PR continues on from #725 and adds the metadata resolve logic to validate the usage of aggregates applied to relationships. The metadata resolve logic is gated behind a new `enable_aggregate_relationships` flag and disabled by default. The new resolve logic lives in `crates/metadata-resolve/src/stages/relationships/mod.rs`, however, most of the actual logic that validates the usage of the aggregate expression with the relationship has been reused from the model aggregate resolve code. Subsequently, that code (`crates/metadata-resolve/src/stages/models/aggregation.rs`) was refactored to return a distinct error type `ModelAggregateExpressionError` that can be composed with the `RelationshipError` type, so the same errors can be returned with the additional context of the relationship they were found in. New metadata resolve error tests have been added in `crates/metadata-resolve/tests/failing/aggregate_expression_in_relationship/*`. Also, two new passing metadata resolve tests have been added to cover the happy case of root field and relationship aggregate expressions: `crates/metadata-resolve/tests/passing/aggregate_expressions/*` JIRA: [V3ENGINE-160](https://hasurahq.atlassian.net/browse/V3ENGINE-160) [V3ENGINE-160]: https://hasurahq.atlassian.net/browse/V3ENGINE-160?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ V3_GIT_ORIGIN_REV_ID: 8cd7040cc9277940641d5ac239d7b34f8c1462c5
2024-06-21 04:08:07 +03:00
name(segments = 3)
)]
fn test_passing_metadata(metadata_json_text: &str) -> anyhow::Result<()> {
Allow supergraph config to appear in subgraphs (#611) ## Description As per [APG-113](https://hasurahq.atlassian.net/browse/APG-113), we would like to remove the separate concept of supergraphs. This is the first step: we allow the supergraph config to appear in subgraphs. The next step will be to remove the non-subgraph version of it. This PR updates the subgraph enum type to allow for supergraph config objects, but does nothing else. This means it should be a no-op for current users, but will be forward-compatible with the eventual goal of the epic. We also throw in a makeshift test framework that we can probably replace with Insta at a later date. <!-- Questions to consider answering: 1. What user-facing changes are being made? 2. What are issues related to this PR? (Consider adding `(close #<issue-no>)` to the PR title) 3. What is the conceptual design behind this PR? 4. How can this PR be tested/verified? 5. Does the PR have limitations? 6. Does the PR introduce breaking changes? --> ## Changelog - Add a changelog entry (in the "Changelog entry" section below) if the changes in this PR have any user-facing impact. See [changelog guide](https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide). - If no changelog is required ignore/remove this section and add a `no-changelog-required` label to the PR. ### Product _(Select all products this will be available in)_ - [x] community-edition - [x] cloud <!-- product : end : DO NOT REMOVE --> ### Type <!-- See changelog structure: https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog --> _(Select only one. In case of multiple, choose the most appropriate)_ - [ ] highlight - [ ] enhancement - [ ] bugfix - [x] behaviour-change - [ ] performance-enhancement - [ ] security-fix <!-- type : end : DO NOT REMOVE --> ### Changelog entry <!-- - Add a user understandable changelog entry - Include all details needed to understand the change. Try including links to docs or issues if relevant - For Highlights start with a H4 heading (#### <entry title>) - Get the changelog entry reviewed by your team --> Supergraph configuration (`CompatibilityConfig`, `AuthConfig`, and `GraphqlConfig`) may now be defined in any subgraph. Note that supergraph configuration may still only be defined once for any given supergraph. <!-- changelog-entry : end : DO NOT REMOVE --> <!-- changelog : end : DO NOT REMOVE --> [APG-113]: https://hasurahq.atlassian.net/browse/APG-113?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ V3_GIT_ORIGIN_REV_ID: a1b9911c4abb332fe37914efd1c3afbbd554a5d0
2024-05-24 11:59:03 +03:00
let metadata_resolve_flags_internal = MetadataResolveFlagsInternal {
enable_boolean_expression_types: true,
Metadata resolve for aggregates over relationships (#731) ## Description This PR continues on from #725 and adds the metadata resolve logic to validate the usage of aggregates applied to relationships. The metadata resolve logic is gated behind a new `enable_aggregate_relationships` flag and disabled by default. The new resolve logic lives in `crates/metadata-resolve/src/stages/relationships/mod.rs`, however, most of the actual logic that validates the usage of the aggregate expression with the relationship has been reused from the model aggregate resolve code. Subsequently, that code (`crates/metadata-resolve/src/stages/models/aggregation.rs`) was refactored to return a distinct error type `ModelAggregateExpressionError` that can be composed with the `RelationshipError` type, so the same errors can be returned with the additional context of the relationship they were found in. New metadata resolve error tests have been added in `crates/metadata-resolve/tests/failing/aggregate_expression_in_relationship/*`. Also, two new passing metadata resolve tests have been added to cover the happy case of root field and relationship aggregate expressions: `crates/metadata-resolve/tests/passing/aggregate_expressions/*` JIRA: [V3ENGINE-160](https://hasurahq.atlassian.net/browse/V3ENGINE-160) [V3ENGINE-160]: https://hasurahq.atlassian.net/browse/V3ENGINE-160?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ V3_GIT_ORIGIN_REV_ID: 8cd7040cc9277940641d5ac239d7b34f8c1462c5
2024-06-21 04:08:07 +03:00
enable_aggregate_relationships: true,
Allow supergraph config to appear in subgraphs (#611) ## Description As per [APG-113](https://hasurahq.atlassian.net/browse/APG-113), we would like to remove the separate concept of supergraphs. This is the first step: we allow the supergraph config to appear in subgraphs. The next step will be to remove the non-subgraph version of it. This PR updates the subgraph enum type to allow for supergraph config objects, but does nothing else. This means it should be a no-op for current users, but will be forward-compatible with the eventual goal of the epic. We also throw in a makeshift test framework that we can probably replace with Insta at a later date. <!-- Questions to consider answering: 1. What user-facing changes are being made? 2. What are issues related to this PR? (Consider adding `(close #<issue-no>)` to the PR title) 3. What is the conceptual design behind this PR? 4. How can this PR be tested/verified? 5. Does the PR have limitations? 6. Does the PR introduce breaking changes? --> ## Changelog - Add a changelog entry (in the "Changelog entry" section below) if the changes in this PR have any user-facing impact. See [changelog guide](https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide). - If no changelog is required ignore/remove this section and add a `no-changelog-required` label to the PR. ### Product _(Select all products this will be available in)_ - [x] community-edition - [x] cloud <!-- product : end : DO NOT REMOVE --> ### Type <!-- See changelog structure: https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog --> _(Select only one. In case of multiple, choose the most appropriate)_ - [ ] highlight - [ ] enhancement - [ ] bugfix - [x] behaviour-change - [ ] performance-enhancement - [ ] security-fix <!-- type : end : DO NOT REMOVE --> ### Changelog entry <!-- - Add a user understandable changelog entry - Include all details needed to understand the change. Try including links to docs or issues if relevant - For Highlights start with a H4 heading (#### <entry title>) - Get the changelog entry reviewed by your team --> Supergraph configuration (`CompatibilityConfig`, `AuthConfig`, and `GraphqlConfig`) may now be defined in any subgraph. Note that supergraph configuration may still only be defined once for any given supergraph. <!-- changelog-entry : end : DO NOT REMOVE --> <!-- changelog : end : DO NOT REMOVE --> [APG-113]: https://hasurahq.atlassian.net/browse/APG-113?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ V3_GIT_ORIGIN_REV_ID: a1b9911c4abb332fe37914efd1c3afbbd554a5d0
2024-05-24 11:59:03 +03:00
};
let metadata_json_value = serde_json::from_str(metadata_json_text)?;
Allow supergraph config to appear in subgraphs (#611) ## Description As per [APG-113](https://hasurahq.atlassian.net/browse/APG-113), we would like to remove the separate concept of supergraphs. This is the first step: we allow the supergraph config to appear in subgraphs. The next step will be to remove the non-subgraph version of it. This PR updates the subgraph enum type to allow for supergraph config objects, but does nothing else. This means it should be a no-op for current users, but will be forward-compatible with the eventual goal of the epic. We also throw in a makeshift test framework that we can probably replace with Insta at a later date. <!-- Questions to consider answering: 1. What user-facing changes are being made? 2. What are issues related to this PR? (Consider adding `(close #<issue-no>)` to the PR title) 3. What is the conceptual design behind this PR? 4. How can this PR be tested/verified? 5. Does the PR have limitations? 6. Does the PR introduce breaking changes? --> ## Changelog - Add a changelog entry (in the "Changelog entry" section below) if the changes in this PR have any user-facing impact. See [changelog guide](https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide). - If no changelog is required ignore/remove this section and add a `no-changelog-required` label to the PR. ### Product _(Select all products this will be available in)_ - [x] community-edition - [x] cloud <!-- product : end : DO NOT REMOVE --> ### Type <!-- See changelog structure: https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog --> _(Select only one. In case of multiple, choose the most appropriate)_ - [ ] highlight - [ ] enhancement - [ ] bugfix - [x] behaviour-change - [ ] performance-enhancement - [ ] security-fix <!-- type : end : DO NOT REMOVE --> ### Changelog entry <!-- - Add a user understandable changelog entry - Include all details needed to understand the change. Try including links to docs or issues if relevant - For Highlights start with a H4 heading (#### <entry title>) - Get the changelog entry reviewed by your team --> Supergraph configuration (`CompatibilityConfig`, `AuthConfig`, and `GraphqlConfig`) may now be defined in any subgraph. Note that supergraph configuration may still only be defined once for any given supergraph. <!-- changelog-entry : end : DO NOT REMOVE --> <!-- changelog : end : DO NOT REMOVE --> [APG-113]: https://hasurahq.atlassian.net/browse/APG-113?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ V3_GIT_ORIGIN_REV_ID: a1b9911c4abb332fe37914efd1c3afbbd554a5d0
2024-05-24 11:59:03 +03:00
let metadata = open_dds::traits::OpenDd::deserialize(metadata_json_value)?;
let resolved = metadata_resolve::resolve(metadata, &metadata_resolve_flags_internal);
match resolved {
Ok(_) => Ok(()),
Err(msg) => panic!("{msg}"),
}
}
#[test_each::file(
glob = "crates/metadata-resolve/tests/failing/**/metadata.json",
name(segments = 3)
)]
#[allow(clippy::needless_pass_by_value)] // must receive a `PathBuf`
fn test_failing_metadata(
metadata_json_text: &str,
metadata_json_path: PathBuf,
) -> anyhow::Result<()> {
let comparison_folder_path = metadata_json_path.parent().unwrap();
let failing_reason = comparison_folder_path.join("expected_error.txt");
Allow supergraph config to appear in subgraphs (#611) ## Description As per [APG-113](https://hasurahq.atlassian.net/browse/APG-113), we would like to remove the separate concept of supergraphs. This is the first step: we allow the supergraph config to appear in subgraphs. The next step will be to remove the non-subgraph version of it. This PR updates the subgraph enum type to allow for supergraph config objects, but does nothing else. This means it should be a no-op for current users, but will be forward-compatible with the eventual goal of the epic. We also throw in a makeshift test framework that we can probably replace with Insta at a later date. <!-- Questions to consider answering: 1. What user-facing changes are being made? 2. What are issues related to this PR? (Consider adding `(close #<issue-no>)` to the PR title) 3. What is the conceptual design behind this PR? 4. How can this PR be tested/verified? 5. Does the PR have limitations? 6. Does the PR introduce breaking changes? --> ## Changelog - Add a changelog entry (in the "Changelog entry" section below) if the changes in this PR have any user-facing impact. See [changelog guide](https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide). - If no changelog is required ignore/remove this section and add a `no-changelog-required` label to the PR. ### Product _(Select all products this will be available in)_ - [x] community-edition - [x] cloud <!-- product : end : DO NOT REMOVE --> ### Type <!-- See changelog structure: https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog --> _(Select only one. In case of multiple, choose the most appropriate)_ - [ ] highlight - [ ] enhancement - [ ] bugfix - [x] behaviour-change - [ ] performance-enhancement - [ ] security-fix <!-- type : end : DO NOT REMOVE --> ### Changelog entry <!-- - Add a user understandable changelog entry - Include all details needed to understand the change. Try including links to docs or issues if relevant - For Highlights start with a H4 heading (#### <entry title>) - Get the changelog entry reviewed by your team --> Supergraph configuration (`CompatibilityConfig`, `AuthConfig`, and `GraphqlConfig`) may now be defined in any subgraph. Note that supergraph configuration may still only be defined once for any given supergraph. <!-- changelog-entry : end : DO NOT REMOVE --> <!-- changelog : end : DO NOT REMOVE --> [APG-113]: https://hasurahq.atlassian.net/browse/APG-113?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ V3_GIT_ORIGIN_REV_ID: a1b9911c4abb332fe37914efd1c3afbbd554a5d0
2024-05-24 11:59:03 +03:00
let metadata_resolve_flags_internal = MetadataResolveFlagsInternal {
enable_boolean_expression_types: true,
Metadata resolve for aggregates over relationships (#731) ## Description This PR continues on from #725 and adds the metadata resolve logic to validate the usage of aggregates applied to relationships. The metadata resolve logic is gated behind a new `enable_aggregate_relationships` flag and disabled by default. The new resolve logic lives in `crates/metadata-resolve/src/stages/relationships/mod.rs`, however, most of the actual logic that validates the usage of the aggregate expression with the relationship has been reused from the model aggregate resolve code. Subsequently, that code (`crates/metadata-resolve/src/stages/models/aggregation.rs`) was refactored to return a distinct error type `ModelAggregateExpressionError` that can be composed with the `RelationshipError` type, so the same errors can be returned with the additional context of the relationship they were found in. New metadata resolve error tests have been added in `crates/metadata-resolve/tests/failing/aggregate_expression_in_relationship/*`. Also, two new passing metadata resolve tests have been added to cover the happy case of root field and relationship aggregate expressions: `crates/metadata-resolve/tests/passing/aggregate_expressions/*` JIRA: [V3ENGINE-160](https://hasurahq.atlassian.net/browse/V3ENGINE-160) [V3ENGINE-160]: https://hasurahq.atlassian.net/browse/V3ENGINE-160?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ V3_GIT_ORIGIN_REV_ID: 8cd7040cc9277940641d5ac239d7b34f8c1462c5
2024-06-21 04:08:07 +03:00
enable_aggregate_relationships: true,
Allow supergraph config to appear in subgraphs (#611) ## Description As per [APG-113](https://hasurahq.atlassian.net/browse/APG-113), we would like to remove the separate concept of supergraphs. This is the first step: we allow the supergraph config to appear in subgraphs. The next step will be to remove the non-subgraph version of it. This PR updates the subgraph enum type to allow for supergraph config objects, but does nothing else. This means it should be a no-op for current users, but will be forward-compatible with the eventual goal of the epic. We also throw in a makeshift test framework that we can probably replace with Insta at a later date. <!-- Questions to consider answering: 1. What user-facing changes are being made? 2. What are issues related to this PR? (Consider adding `(close #<issue-no>)` to the PR title) 3. What is the conceptual design behind this PR? 4. How can this PR be tested/verified? 5. Does the PR have limitations? 6. Does the PR introduce breaking changes? --> ## Changelog - Add a changelog entry (in the "Changelog entry" section below) if the changes in this PR have any user-facing impact. See [changelog guide](https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide). - If no changelog is required ignore/remove this section and add a `no-changelog-required` label to the PR. ### Product _(Select all products this will be available in)_ - [x] community-edition - [x] cloud <!-- product : end : DO NOT REMOVE --> ### Type <!-- See changelog structure: https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog --> _(Select only one. In case of multiple, choose the most appropriate)_ - [ ] highlight - [ ] enhancement - [ ] bugfix - [x] behaviour-change - [ ] performance-enhancement - [ ] security-fix <!-- type : end : DO NOT REMOVE --> ### Changelog entry <!-- - Add a user understandable changelog entry - Include all details needed to understand the change. Try including links to docs or issues if relevant - For Highlights start with a H4 heading (#### <entry title>) - Get the changelog entry reviewed by your team --> Supergraph configuration (`CompatibilityConfig`, `AuthConfig`, and `GraphqlConfig`) may now be defined in any subgraph. Note that supergraph configuration may still only be defined once for any given supergraph. <!-- changelog-entry : end : DO NOT REMOVE --> <!-- changelog : end : DO NOT REMOVE --> [APG-113]: https://hasurahq.atlassian.net/browse/APG-113?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ V3_GIT_ORIGIN_REV_ID: a1b9911c4abb332fe37914efd1c3afbbd554a5d0
2024-05-24 11:59:03 +03:00
};
let error_untrimmed = fs::read_to_string(failing_reason)?;
Allow supergraph config to appear in subgraphs (#611) ## Description As per [APG-113](https://hasurahq.atlassian.net/browse/APG-113), we would like to remove the separate concept of supergraphs. This is the first step: we allow the supergraph config to appear in subgraphs. The next step will be to remove the non-subgraph version of it. This PR updates the subgraph enum type to allow for supergraph config objects, but does nothing else. This means it should be a no-op for current users, but will be forward-compatible with the eventual goal of the epic. We also throw in a makeshift test framework that we can probably replace with Insta at a later date. <!-- Questions to consider answering: 1. What user-facing changes are being made? 2. What are issues related to this PR? (Consider adding `(close #<issue-no>)` to the PR title) 3. What is the conceptual design behind this PR? 4. How can this PR be tested/verified? 5. Does the PR have limitations? 6. Does the PR introduce breaking changes? --> ## Changelog - Add a changelog entry (in the "Changelog entry" section below) if the changes in this PR have any user-facing impact. See [changelog guide](https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide). - If no changelog is required ignore/remove this section and add a `no-changelog-required` label to the PR. ### Product _(Select all products this will be available in)_ - [x] community-edition - [x] cloud <!-- product : end : DO NOT REMOVE --> ### Type <!-- See changelog structure: https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog --> _(Select only one. In case of multiple, choose the most appropriate)_ - [ ] highlight - [ ] enhancement - [ ] bugfix - [x] behaviour-change - [ ] performance-enhancement - [ ] security-fix <!-- type : end : DO NOT REMOVE --> ### Changelog entry <!-- - Add a user understandable changelog entry - Include all details needed to understand the change. Try including links to docs or issues if relevant - For Highlights start with a H4 heading (#### <entry title>) - Get the changelog entry reviewed by your team --> Supergraph configuration (`CompatibilityConfig`, `AuthConfig`, and `GraphqlConfig`) may now be defined in any subgraph. Note that supergraph configuration may still only be defined once for any given supergraph. <!-- changelog-entry : end : DO NOT REMOVE --> <!-- changelog : end : DO NOT REMOVE --> [APG-113]: https://hasurahq.atlassian.net/browse/APG-113?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ V3_GIT_ORIGIN_REV_ID: a1b9911c4abb332fe37914efd1c3afbbd554a5d0
2024-05-24 11:59:03 +03:00
let error = error_untrimmed.trim();
match serde_json::from_str(metadata_json_text) {
Allow supergraph config to appear in subgraphs (#611) ## Description As per [APG-113](https://hasurahq.atlassian.net/browse/APG-113), we would like to remove the separate concept of supergraphs. This is the first step: we allow the supergraph config to appear in subgraphs. The next step will be to remove the non-subgraph version of it. This PR updates the subgraph enum type to allow for supergraph config objects, but does nothing else. This means it should be a no-op for current users, but will be forward-compatible with the eventual goal of the epic. We also throw in a makeshift test framework that we can probably replace with Insta at a later date. <!-- Questions to consider answering: 1. What user-facing changes are being made? 2. What are issues related to this PR? (Consider adding `(close #<issue-no>)` to the PR title) 3. What is the conceptual design behind this PR? 4. How can this PR be tested/verified? 5. Does the PR have limitations? 6. Does the PR introduce breaking changes? --> ## Changelog - Add a changelog entry (in the "Changelog entry" section below) if the changes in this PR have any user-facing impact. See [changelog guide](https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide). - If no changelog is required ignore/remove this section and add a `no-changelog-required` label to the PR. ### Product _(Select all products this will be available in)_ - [x] community-edition - [x] cloud <!-- product : end : DO NOT REMOVE --> ### Type <!-- See changelog structure: https://github.com/hasura/graphql-engine-mono/wiki/Changelog-Guide#structure-of-our-changelog --> _(Select only one. In case of multiple, choose the most appropriate)_ - [ ] highlight - [ ] enhancement - [ ] bugfix - [x] behaviour-change - [ ] performance-enhancement - [ ] security-fix <!-- type : end : DO NOT REMOVE --> ### Changelog entry <!-- - Add a user understandable changelog entry - Include all details needed to understand the change. Try including links to docs or issues if relevant - For Highlights start with a H4 heading (#### <entry title>) - Get the changelog entry reviewed by your team --> Supergraph configuration (`CompatibilityConfig`, `AuthConfig`, and `GraphqlConfig`) may now be defined in any subgraph. Note that supergraph configuration may still only be defined once for any given supergraph. <!-- changelog-entry : end : DO NOT REMOVE --> <!-- changelog : end : DO NOT REMOVE --> [APG-113]: https://hasurahq.atlassian.net/browse/APG-113?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ V3_GIT_ORIGIN_REV_ID: a1b9911c4abb332fe37914efd1c3afbbd554a5d0
2024-05-24 11:59:03 +03:00
Ok(metadata_json_value) => {
match open_dds::traits::OpenDd::deserialize(metadata_json_value) {
Ok(metadata) => {
match metadata_resolve::resolve(metadata, &metadata_resolve_flags_internal) {
Ok(_) => panic!("Expected to fail with {error}"),
Err(msg) => similar_asserts::assert_eq!(error, msg.to_string()),
}
}
Err(msg) => similar_asserts::assert_eq!(msg.to_string(), error),
};
}
Err(msg) => {
similar_asserts::assert_eq!(msg.to_string(), error);
}
};
Ok(())
}