ElanoryaJewelry AI
サーバーが受け付ける法的文書のバージョンは、自身のビルドにある値だけです
何も変えていないのに、登録も、GoogleやAppleでのサインインも、同意の送信も、生成も、同じ役に立たないエラーで失敗しはじめます。このページは、それを生んでいる比較と、アプリが決して伝えないことを説明します。
サーバーがほかの何よりも先に比べていること
法的文書への同意を伴うリクエストは、どれもバージョンの値を一緒に運びます。サーバーはその値を、記録しておく情報としては扱いません。条件として扱います。経路はこの項目を、サーバー自身のビルドが持つ1つの値に固定しているため、違う値を持つリクエストは、残りの中身が検討される前に拒否されます(apps/api/src/auth/auth.controller.ts)。
アプリの中で何をしても結果が変わらないのは、これが理由です。値はインストールに埋め込まれています。古いビルドは自身がビルドされたときの値を送り、サーバーは自身がビルドされたときの値と比べます。2つが違えば、リクエストはそこで終わります。
同じ経路は、文書本文のダイジェスト、つまり本文から計算される要約値も確認します。文書の中に印字された連絡先や事業者情報を編集するとこのダイジェストが変わり、古いビルドはサーバーがもう認識しない値を送ることになります。ダイジェストの変更が及ぶのは同意の有効性ではなく、クライアント側の互換性です。すでに記録された同意が今も有効かどうかはバージョンの値だけで決まるため、ダイジェストが変わったこと自体が既存の利用者を同意の画面へ戻すわけではありません。そもそもなぜ同意を求める画面が出るのかは別の問いであり、このページでは決着させません。
この拒否が届くリクエスト
この条件は、何かに同意する瞬間だけに限られてはいません。
- 登録が拒否されます。
- 古い値を持つビルドからアカウントを作成することはできず、リクエストは経路の時点で退けられます(apps/api/src/auth/auth.controller.ts)。
- GoogleやAppleでのサインインが拒否されます。
- これらのサインインも同じ管理された項目を運び、同じ比較に行き当たります。
- 同意の送信が拒否されます。
- 送信そのものが管理されたリクエストの1つです。多くの出品者がこの失敗に最初に出会う場所が同意画面なのは、そのためです。
- 生成のリクエストが拒否されます。
- 遮断は入り口の画面で終わりません。生成を求めるリクエストも同じように拒否されます。
- 返ってくるのは、一般的な不正なリクエストというエラーです。
- バージョンも、ビルドの識別子も、取るべき行動も含みません。応答の中に、ほかの形の崩れたリクエストと区別できるものはありません。
拒否が画面のどこに現れるか
全行の出典は同じです(apps/api/src/auth/auth.controller.ts)。静的なソースとして読んだものであり、リクエストは送っておらず、動作中のシステムも観察していません。
| していたこと | 返ってくるもの | それを決めたもの |
|---|---|---|
| アカウントを作成する | 不正なリクエストというエラー | 自分のビルドに埋め込まれたバージョンの値 |
| GoogleまたはAppleでサインインする | 不正なリクエストというエラー | 同じ値を、同じ経路で確認している |
| 文書に同意する | 保存の失敗 | 何かが保存される前に送信が拒否される |
| 画像を生成する | 不正なリクエストというエラー | リクエストが同じ管理された項目を運んでいる |
| 文書の本文だけが編集されたあとの、上記のいずれか | 不正なリクエストというエラー | 自分のビルドが送るダイジェストを、サーバーがもう受け付けない |
作業中にこれが奪うもの
午前中の撮影を終え、編集にかかる最初のリクエストが拒否される。
失敗がサインインと生成に同時に広がっているかどうかを確かめてください。その広がりは1つの条件の特徴であり、そう読み取ることで、2つの問題を追いかける時間を使わずに済みます。
同意画面が保存の失敗を報告するので、内容をもう一度入力する。
拒否より前に保存されるものはありません。同じビルドからの2回目の試みは同じ値を送り、同じように答えられます。
この問題を、サービス障害として引き上げる。
原因ではなく形を伝えてください。どのリクエストが失敗するのか、メッセージが何と言っているのかです。ここで読んだソースは、どの配備の現在の状態も示しません。
作業の途中で2台目の端末を追加したが、サインインできない。
登録と、GoogleやAppleでのサインインは同じ条件の後ろにあるため、古いビルドは作業の途中ではなく入り口で止められます。
両側が静かにずれていかない理由
アプリが表示する本文と、サーバーが受け付けるダイジェストは、2か所に手で貼り付けられた2つの定数ではありません。1つの生成器が、両側に向けて同時に書き出しています。両者が黙ってずれていくことが構造として起こりにくいのは、そのためです。この関係は法的な取り決めを扱うファイルに記録されており(apps/api/src/legal/legal-contract.ts)、そこでは両方の書き手としてapps/jewelry-mobile/scripts/legal-manifest.mjsが挙げられています。
これは2つのファイルがどのように生み出されるかについての記述であって、リリースごとに付いてくる保証ではありません。何かが変わるたびに生成器が実際に実行されているかどうかは、進め方と継続的インテグレーションの問題です。コードがそれを強制することはできず、このページもできるとは主張しません。
出品者にとっての帰結は限られています。両側が動くときは一緒に動くように書かれているので、行き当たる食い違いは、インストールしているビルドと、それが話しかけているサーバーとの間のものです。同じビルドの半分どうしの食い違いではありません。
このページが開いたままにする問い
上の内容はすべてソースファイルを読んだものです。ここでは動作中のシステムを観察しておらず、ごく普通の問いのいくつかは、そもそもソースからは答えられません。
- 本番でどの法的文書のバージョンが動いているのか、どのビルドが現在ストアで配布されているのか。コードが示すのは定数であって、現在の状態ではありません。
- 文書に何が書かれているのか、何を対象にしているのか、利用者に何を与えるのか。このページは仕組みを説明するものであり、どの文言の内容についても何も主張しません。
- 特定の文言が確認を受けているのか、ウェブサイトで公開されているのか。その面は、ここで読んだコードの外にあります。
- 新しいビルドがいつ、どの経路で、どんな予定で現れるのか。このページのどこも、リリースの約束ではありません。
- 購入、復元、ストアの請求の失敗。これらはそれぞれ別の理由で拒否されるもので、この比較には支配されていません。
- セッションの挙動、確認のしきい値、そのほかサインインの経路のあらゆるパラメーター。
よくある質問
これはサービスが停止しているということですか。
このページにはそれを判断できず、根拠にしているソースにもできません。言えるのは、自分のビルドにあるバージョンの値とサーバーのビルドにある値が食い違うと、まさにこの失敗が起きるということです。登録、GoogleやAppleでのサインイン、同意、生成にわたって、一般的な不正なリクエストというエラーとして返り、それ以上のものはありません(apps/api/src/auth/auth.controller.ts)。
更新が必要だとアプリが教えてくれますか。
いいえ。この経路には更新を求めるメッセージがありません。拒否はそのまま不正なリクエストとして返り、同意画面では保存に失敗したように読めます。案内がまったくないことが、この失敗が原因のないもののように見える理由です。
文書の中の連絡先が変わっただけです。それでどうして何かが壊れるのですか。
経路はバージョンの値と並べて、文書本文のダイジェストも確認します。印字された本文を編集するとダイジェストが変わるため、古いビルドはサーバーがもう受け付けない値を送ります。影響が及ぶのはクライアント側の互換性です。すでに記録された同意が今も有効かどうかは、ダイジェストではなくバージョンの値で判断されます(apps/api/src/auth/auth.controller.ts)。
サーバーが今どのバージョンで動いているのかを知ることはできますか。
ここで説明していることからは分かりません。ソースが示すのはビルドが運ぶ値であって、配備されているものでも、ストアが配布しているものでもありません。現在のバージョンについての言明はこの根拠の外に出てしまうため、何も述べていません。