SCSKの畑です。
今回は小ネタですが、アプリケーション開発中に少し戸惑った内容であることと、（あまりにも当たり前すぎて？）Web 上にあまり情報が見つけられなかったことも相まってエントリとして残しておこうと思っての投稿です。
小ネタ本題
先般投稿した一連のエントリの通り、アプリケーションのバックエンドからフロントエンドまで広く手を入れることになりましたが、その際に Amplify・AppSync 周りで遭遇した内容となります。
これら一連の改修においては当然ながら AppSync API（スキーマ定義）も複数変更されており、上記エントリで言及した非同期処理用インターフェース/ラッパー用クエリの追加もあれば、同クエリ経由で非同期実行するように変更することで不要となったクエリ/ミューテーションの削除もありました。上記エントリで触れたテーブルの更新差分を導出する処理を例に挙げますと、一連の処理が AppSync クエリとして実装されていたところを
- 差分計算処理：非同期処理用インターフェース/ラッパー用クエリ経由の実行に変更
- 差分計算結果取得処理：S3 署名付き URL 経由での取得処理に変更
のように変更したため、元々の AppSync クエリは結果的に不要となり、Amplify のスキーマ定義からも削除しました。
一方で、差分計算結果のフォーマット（型情報）自体は変更する必要がなかったため、元々の AppSync クエリの返り値として Amplify のスキーマに定義していたものを引き続き使用しようと考え残しておきました。スキーマ定義の詳細については昨年度の以下エントリをご参照ください。
name: TypeError message: can't access property "deleted_rows_info", models.DataDiffInfo is undefined
回避策
先述の通り、Amplify が生成する型情報に含めるためには廃止したクエリを（使わないのに）再度定義する必要があるということで、さすがにそれは目的と手段を履き違えているため、大人しくこれらの型情報を定義するための composable を作成することで対応しました。
Amplify 経由で定義する方が正直楽ではあるので最初はその方向性で調査していたのですが情報がまるでなく。。一旦上記で解決したこともあり直近では特に調査していないのですが、もし今後続報があれば本エントリを更新したいと思います。
まとめ
先述の通り、Amplify のスキーマの目的というか位置づけを考えるとそのような挙動になることは納得の行くところですが、そもそも普通は Amplify/AppSync で使用しない型情報を明示的に Amplify のスキーマに定義することはないと思うので、そう考えるとある意味盲点と言えるかもしれません。。アプリケーション開発中に AppSync クエリの改廃自体は発生し得ることだとは思いますが、今回のように AppSync のクエリとしては不要になったが型情報は継続して使用したいというのもレアケース寄りだと思いますし・・
本記事がどなたかの役に立てば幸いです。