概述
我们介绍了 模式检查，并讨论了它们在你的 图管理中扮演的重要角色。除了 组成检查（确保对 子图的更改可以成功地与其他子图进行组合），我们还可以在工具带上添加另一个工具： 操作检查。
操作 checks 将模式更改与过去在客户端上进行的操作进行比较，以确保我们不会对从我们的 图使用数据的客户端进行任何重大更改。
在这节课中，我们将
- 了解如何在 Studio中浏览 操作检查
- 了解如何在 Studio 中覆盖标记更改
- 了解如何在 Studio 中重新运行检查
更新子图
Airlock 团队不仅在致力于开发新功能，还一直关注着他们 图表 的运行状况以及客户如何使用它。他们最近发现移动客户端和 web 客户端都在使用架构的 featuredListings 字段，并使用他们收到的结果实施了额外的逻辑。
featuredListings 字段 返回一个 Listing 对象的列表。更具体地说，它返回正好八个包。但是，当只显示这些包中的 六个 个时，web 客户端的布局效果最好。同时，移动客户端发现仅显示 三个 才最适合自己的用户。因此，目前两家客户端都获取了多余的包。
我们不希望客户端自己实施额外的逻辑，所以让我们帮助他们修复它。让我们从我们的 CI/CD 工作流的开始处着手。
👩🏽🏫 上市团队的 Lisa 创建了 listings 子图架构，通过向 featuredListings 字段 中的新 变量 添加 featuredListings 字段，使其对客户端查询更加灵活。
添加新变量
现在让我们了解 listings 子图。为了自定义可在 UI 中显示的特色商品数量，Lisa 已向 featuredListings 字段 中添加了一个新的非空 变量 limit。
"A curated array of listing packages to feature on the homepage"featuredListings(limit: Int!): [Listing!]!
他们还相应地更新了 转换器和 数据源来实现此新架构更改。
featuredListings: async (_, { limit }, { dataSources }) => {const featuredListings = await dataSources.listingsAPI.getFeaturedListings(limit);return featuredListings;};
准备好代码更改后，让我们执行工作流中的下一步：局部运行架构检查。
运行 rover subgraph check 命令不会产生任何 composition错误，但现在 Operation检查已经对某些更改失败！让我们深入了解一下错误：
Checking the proposed schema for subgraph listings against airlock-managed-fed@stagingCompared 1 schema changes against 16 operations┌────────┬────────────────────┬─────────────────────────────────────────────────────────────────┐│ Change │ Code │ Description │├────────┼────────────────────┼─────────────────────────────────────────────────────────────────┤│ FAIL │ REQUIRED_ARG_ADDED │ field `Query.featuredListings`: required argument `limit` added │└────────┴────────────────────┴─────────────────────────────────────────────────────────────────┘View full details at https://studio.apollographql.com/graph/airlock-managed-fed/operationsCheck/{URL}error[E030]: This operation check has encountered 1 schema change that would break operations from existing client traffic.The changes in the schema you proposed are incompatible with graph airlock-managed-fed@staging. See https://apollo.graphql.net.cn/docs/studio/schema-checks/ for more information on resolving operation check errors.
在以往，客户端 查询 featuredListings 字段 不带 limit 参数。如果 Listings 团队将此更新推送到 子图而不给下游客户端机会更新其查询，他们可能正在引入重大更改。
Operation检查会评估对 子图进行的建议更改是否会影响在一定时间范围内针对架构执行的任何 GraphQL操作。在我们团队的情况下，featuredListings查询每天运行很多次，每当 Airlock 收到更多有兴趣预订行程的访客时就会运行。
注意：默认情况下，GraphOS配置为针对过去七天内执行的 操作运行检查。要了解如何自定义此时间范围（以及其他配置设置），请参阅 有关架构检查配置的 Apollo 文档。
由于 Airlock 配置为使用托管联合，因此有关操作用法的这些分析数据将自动收集并存储，供我们的团队在 Studio 中查看。有关操作由客户端调用次数的信息可以深入了解架构的哪些部分可以安全更改甚至移除。
我们可以看到以下有关GetFeaturedListings 操作的数据：
要修复添加新的limit 参数而导致的错误，来自商品信息团队的丽莎将该参数修改为可以为 null，并将8设置为默认值。
"A curated array of listings to feature on the homepage"featuredListings(limit: Int = 8): [Listing!]!
通过将参数设置为可为空，不会引入破坏性更改，并且现有客户端查询会照常工作，检索八个商品信息以作为默认值显示。
在运行另一个本地架构检查后，我们会看到以下结果
Checking the proposed schema for subgraph listings against airlock-managed-fed@stagingCheck Result:Compared 1 schema changes against 16 operations┌────────┬────────────────────┬─────────────────────────────────────────────────────────────────┐│ Change │ Code │ Description │├────────┼────────────────────┼─────────────────────────────────────────────────────────────────┤│ PASS │ OPTIONAL_ARG_ADDED │ field `Query.featuredListings`: optional argument `limit` added │└────────┴────────────────────┴─────────────────────────────────────────────────────────────────┘View full details at https://studio.apollographql.com/graph/airlock-managed-fed/operationsCheck/3a566c0d-b46f-49f9-b5b5-3a6bde6560f2?variant=staging
所有问题已解决！丽莎可以再次运行整个 CI/CD 流程，使更改实际应用于生产中。当此更改实际应用后，客户端随后可以根据需要修改查询，以包括新的limit 参数。Web 客户端可以将其设置为6，而移动客户端可以将其设置为3。不再需要在客户端添加额外的逻辑了！
我们还没有完成 Airlock 图维护！Lisa 在 listings 子图中发现了另一个 字段，该 字段需要更新。在这种情况下，应该删除 字段，因为似乎没有人使用它。
删除字段
一个重新设计主页的废弃项目中的旧 字段仍然存在于架构中： Listing.photoInHexagonShape 字段。
一个旧的主页模型展示了此 字段的预期用法。
为了让架构精简且易于维护，Lisa 选择完全删除 Listing.photoInHexagonShape 字段。
当我们在本地运行 架构检查时，更改会导致 操作错误。我们可以在终端中看到它：
Checking the proposed schema for subgraph listings against airlock-managed-fed@stagingCompared 1 schema changes against 17 operations┌────────┬───────────────┬─────────────────────────────────────────────────────┐│ Change │ Code │ Description │├────────┼───────────────┼─────────────────────────────────────────────────────┤│ FAIL │ FIELD_REMOVED │ type `Listing`: field `photoInHexagonShape` removed │└────────┴───────────────┴─────────────────────────────────────────────────────┘View full details at https://studio.apollographql.com/graph/airlock-managed-fed/operationsCheck/35201113-cdbe-4a79-847b-856acd362bbf?variant=stagingerror[E030]: This operation check has encountered 1 schema change that would break operations from existing client traffic.The changes in the schema you proposed are incompatible with graph airlock-managed-fed@staging. See https://apollo.graphql.net.cn/docs/studio/schema-checks/ for more information on resolving operation check errors.
我们还可以在 Studio 中的 检查页面中或通过终端输出中提供的链接查看这些结果。基于过去针对我们的 图表执行的 操作，我们看到一条警告，即删除此 字段可能会导致下游客户端出现重大更改。
为解决此 操作检查错误，丽莎首先需要确保在此 字段被移除之前，没有人在依靠此 字段。为此，他们需要首先用 @deprecated 指令标记模式文件中的 字段，并提供该字段弃用的原因（任何使用该 字段的下游客户端都可以看到）。通过在移除字段之前将此弃用状态告知客户端，每个人都有机会更新自己的查询，避免出现破坏性更改。
photoInHexagonShape: String @deprecated(reason: "Use photo instead.")
运行本地模式检查时，我们不会在终端看到任何错误
Checking the proposed schema for subgraph listings against airlock-managed-fed@stagingCheck Result:Compared 1 schema changes against 17 operations┌────────┬──────────────────┬────────────────────────────────────────────────────────┐│ Change │ Code │ Description │├────────┼──────────────────┼────────────────────────────────────────────────────────┤│ PASS │ FIELD_DEPRECATED │ type `Listing`: field `photoInHexagonShape` deprecated │└────────┴──────────────────┴────────────────────────────────────────────────────────┘View full details at https://studio.apollographql.com/graph/airlock-managed-fed/operationsCheck/9e2333a4-82bd-4ceb-a554-ca93e52ff35f?variant=staging
我们可以看到该 字段已在 Studio 中弃用：
一段时间后，我们确信任何用于查询 Listing.photoInHexagonShape 字段的历史下游客户端都已将其从查询中移除。
现在，丽莎可以彻底移除 Listing.photoInHexagonShape 字段及其 @deprecated 指令。我们将再次执行 CI/CD 流程，运行本地模式检查并在 Studio 中调查 操作检查错误。在了解到这一更改是安全的之后，我们可以覆盖产生的操作错误。
将更改标记为安全
在 Studio 中的错误视图中，我们可以选择 覆盖下拉选项，然后点击 将更改标记为安全。
此操作告诉 模式检查流程，在将来的 操作检查中可以忽略这一具体更改，但对于任何将来的更改，它并不会对 操作本身亮绿灯！
例如，在上述示例中，我们看到GetFeaturedListings是带有中断更改标志的操作名称。此操作查询 Airlock 中的所有Listing对象，因此它与我们刚刚对Listing类型所做的更改有关。即使我们已批准并覆盖了因删除Listing.photoInHexagonShape 字段而导致的错误，新的任何中断性更改引入到GetFeaturedListings 操作中都会在未来继续标记。
同样，如果房屋租赁团队进行另一个中断更改（例如更改字段的返回类型在Listing上，或完全删除其另一个字段），他们将遇到新的 操作检查失败。
注意：覆盖是在操作逐个操作设置的。除了将特定更改标记为安全外，我们还可以忽略对整个 操作的中断更改。例如，我们可以指示GraphOS始终忽略因影响GetFeaturedListings 操作的更改而导致的错误。当操作范围仅限于你不主动支持的客户端或客户端版本时，此选项很有用。否则，最佳做法是逐个修复或批准操作的标记更改。
设置覆盖后，我们可以在 Studio 中点击 再次运行检查 检查页面中，在此重新运行检查。
这次，操作检查将使用我们在此操作上设置的新配置，并且我们移除的 Listing.photoInHexagonShape 字段将不再引发警报。
现在，我们可以运行我们在上一课中详述的相同 CI/CD 流程，将这些架构更改引入暂存，然后引入生产。
实践
关键信息
- 操作检查会针对架构考虑历史操作，以确保更新 子图不会为客户端引入重大更改。
- 在 操作检查期间发生的错误可以在 Studio 中覆盖。
- 操作检查覆盖可以针对每个操作进行设置，使你可以标记特定更改已批准，或完全忽略操作。
接下来
我们引入了 组合和 操作检查，以便对我们对 Airlock 架构的更改有更多的信心。将这些步骤纳入工作流程后，我们可以确保 Airlock 的开发者可以提交他们的更改，而不会意外地为其他团队或客户端带来损害。
在下节中，我们将看到通过引入使用报告我们如何提升对图形的洞察。
分享您关于本小节的问题和评论
您的反馈有助于我们提升！如果您卡住了或困惑了，请告诉我们，我们会帮您。所有评论都是公开的，并且必须遵循 Apollo 行为准则。请注意，已解决的评论或已回复的评论可能会被移除。
您需要一个 GitHub 账户才能在下方发表评论。没有吗？ 相反，在我们的 Odyssey 论坛中发表评论。