kintoneの公式ドキュメントには記載が無いのですが、webHookを使う場合には、kintoneレコードを文字列化したサイズが1Mバイト超えるとGAIA_WP01エラーに成るようです。
でも、Administrator権限が無い一般利用者には、webHook起動失敗メッセージ（GAIA_WP01）は観えないので、「いつの間にか結果不正になった」という風に観えてしまいます。
そこで、kintoneの詳細レコード編集中に、GAIA_WP01エラーに成る可能性をチェックして一般利用者に処置を促すことができるような方法（チェックタイミング・イベントやチェック条件等）を、教示していただけないでしょうか？
※GAIA_WP01: Webhookで送信される通知のペイロードのサイズが、上限の1MBを超えています。
こんなに大きなサイズのレコードは、subTableの行数と項目数の積が大きな場合でしょうが、沢山のデータを入力した時こそ、そのデータは重要なので、「正しくwebHookでデータ加工できるのか否か？」を 無難にチェック出来るのが良いでしょう。
5件のコメント
どんなタイミングにチェックするのがいいかってのは外に聞くものではなくて社内で揉むものでは？と思いますが、
チェックのタイミングあるあるとして↓こんな感じだとおもいます。
・保存ボタン押した時に「kintoneレコードを文字列化したサイズが1Mバイト越え」ていたらエラーメッセージを出す
・サイズチェック用のボタンを用意してクリックした時に「kintoneレコードを文字列化したサイズが1Mバイト越え」ていたらエラーメッセージを出す
・どこかのフィールドの値を変更したときに「kintoneレコードを文字列化したサイズが1Mバイト越え」ていたらエラーメッセージを出す
※あくまでも、参考程度にお願いしますね。その辺にいるkintoneユーザーのイチ意見ですし、正しいとは限りません。
応答ありがとうございます。
ご提案内容は、大体、下記の実装と 似たようなことかと思いますが、ダメでした。
・チェックタイミングは、subTableのchangeイベントで、subTableのvalidaterのパラメタに「JSON.stringify(status.record).length」の値を渡す方式。
・ダメだった、チェック条件は、validater内で「JSON.stringify(status.record).length < 1024*1024」チェックする。
この場合、GAIA_WP01エラーが再発しました。 多分、Webhookで生成されるpost リクエストのbodyは、status.recordをbase64か何か 多段の変換をしていて、JSON.stringify(status.record).length より 大きなデータを生成してるのでしょう。
・そこで、チェック条件を 少しきつくして、「JSON.stringify(status.record).length < 512*1024」でも、GAIA_WP01エラーが再発しました。
・さらにチェック条件を 少しきつくして、「JSON.stringify(status.record).length < 256*1024」にすると、安定してGAIA_WP01エラーは回避できるようになりました。
でも、この「JSON.stringify(status.record).length < 256*1024」という条件は、webHook起動失敗メッセージ（GAIA_WP01）の内部処理での「kintoneレコードを文字列化したサイズが1Mバイト越え」の条件と一致していないし、多分 KintoneのGAIA_WP01チェック条件よりキツ目になっているでしょう。
このままでは「kintoneが 本来受付できてwebhookもできるようなサイズのrecordなのに、私が勝手に キツ目なチェックを入れて、制限した」ということになります。
もう少し「kintoneのGAIA_WP01チェック条件と 概ね 同じ条件だ」と言えるような、チェック条件は無いものでしょうか？
例えば、webhook側で受け取ったpostDataは、JSON形式の電文として読み取れる形式なので、エンコード方式とかを調べてエンコーディングしてみるとか、webhook側で受け取ったHTTP headerとかstatus.record以外のデータのサイズを足してみるとか、kintoneのwebhookのhttpリクエストデータをリバースエンジニアリングをした結果が反映された、「kintoneレコードを文字列化したサイズが1Mバイト越え」のチェック関数が 何処かに 転がってはいないものでしょうか？
JSON.stringify(status.record).length
1バイト文字しかない前提ですかね？
多分だけど、blobとか使ってバイト数を求めたほうがよいと思います。
webHookがPOST HTTP requestする時のhttp headerのcontent-lengthの値を推測すればよいのでしょうか？
そうだとすると、http headerの内容は無関係で、webHookのbody部として届いたJSON形式電文と同様なobjectを組み立てて、
「(new Blob([JSON.stringify({
id: '64文字', type: 'UPDATE_RECORD', app: { id: 'アプリケーションID', name: 'アプリケーション名' },
recordTitle: 'レコードのタイトル', url: 'kintoneの詳細レコード表示URL' ,
record: status.record
})])).size
」
で、計算できそうですよね。
でも、kintoneのGAIA_WP01チェック条件の境界値を求めようとして、「後1行subTableに行データを追加するGAIA_WP01エラーとなるようなレコード」を作って、
そのレコードの長さを測れば、誤差数百バイト（subTable1行相当サイズ）程度でGAIA_WP01チェック条件の境界値を見つけることができるかと思ったのですが、、
・JSON.stringify.length= 476013。
・(new Blob([JSON.stringify()])).size = 603121。
どうにも、１M（1048576）という数値から数百Kバイトの乖離がありましたね。
多分、これらの何方の計算式も、kintoneのGAIA_WP01チェック条件とは異なっているということなのでしょう。
また、changeイベントの度にチェックするにしては、（new Blob([JSON.stringify]))の関数が重くて、緩慢な動作になったような気もします。 「changeイベントで毎回」は、チェックタイミングとして不適切だという事ですね。
かといって、「保存時に1回だけチェック」というタイミングだと、「2百行前後のsubTablleを入力した後、何十行だか解らない行数のsubTableのデータを削除せよ」という趣旨のエラーメッセージとなり、それを言われる立場に立つと 理不尽で、遅いチェック・タイミングだと言われます。
ベストは望み得ないとしても、操作に対する応答性能と正確性のバランスをとった チェック・タイミング＆チェック条件というのは無いモノでしょうか？
また、kintoneの内部動作に詳しくなければ、「バランスをとった方式だ」と断言できないでしょうから、、”社内で検討”できるモノでは在りえませんよね？
オヤ！？バイト数の求め方を教えてあげたことについてのお礼の言葉が未だ無いようですね。
>changeイベントの度にチェックするにしては、～
>「保存時に1回だけチェック」というタイミングだと、～
>kintoneの内部動作に詳しくなければ、「バランスをとった方式だ」と断言できない
保存時もchangeイベントのときにチェックを走らせた場合、その認識（重い、面倒）で合ってると思う。
でもそのタイミングと、何らかの他のボタンをおすというタイミングしかないなら、ぶっちゃけどれえらんでもいっしょだとおもいます。
その上で実際に使う人がどの仕様だったら許せるか？を社内で揉むしかないですよね
kintoneの内部動作に詳しい人に「バランスとった方式はこれだ」と断言してほしいなら、プロにお金出してお願いするのがはやいですよ。
・・・にしても、提案すれば「これはいやだ、あれはいやだ」「まだ〇〇の提案がないですね」みたいにレスが来たり
そういうレスを他の誰かがされているのを見たりするの正直疲れました。
仕事でもなんでもないボランティアにそこまで求めます？？って
※「プロにお金出して」って提案すればきっと「コストが～」とか思われるんでしょうね。
老婆心ながら申しあげますが、こういうコミュニティでのマナーをちょっと身に着けたほうが良いと思いますよ。
まあ、無料のコミュニティなんであなたのレスを無視すれば良いだけだとは思うんですけど。
あなたは困って書き込まれているんでしょうし、無視するわけにもね。ただ、疲れました。
↓kintoneの性能上の考慮点と改善策（参考になるかも）
https://kintone.cybozu.co.jp/kintone-signpost/guide/performance.html
↓プロの人達はここから探せるのでこちらからどうぞ。
https://partner.cybozu.co.jp/