Repository navigation
chore: 0.1.1 公開前の品質関門（AI slop 排除・品質 MAX） - #14
Merged
Merged
Conversation
zankyo-wrapper は 100755 なのに extensions/zankyo だけ 100644 だった。 zip 化は build-layer.mts の chmod で補正されるが、Layer ディレクトリを 直接使う経路では external extension が Permission denied で起動しない。
rust-version は 1.85 だったが、ロック済みの aws-sdk-* / aws-smithy-* は 1.94.1 を要求していた（cargo metadata で最大値を確認）。 宣言値を 1.94.1 に上げ、proxy/Cargo.toml の値でビルドを確かめる rust-msrv ジョブを CI に追加する。MSRV が上がり clippy の manual_is_multiple_of が有効になったため、Luhn 判定を is_multiple_of にする。 配布物は Layer zip / SAR / npm なので publish = false を明示する。
tokio の io-util / signal と hyper-util の server は、src・tests の どこからも使っていない（サーバは hyper::server::conn::http1 を直接使う）。 ZankyoError::Io / Hyper も生成箇所が無く、hyper のエラーはすべて map_err で Upstream に変換している。モジュール doc の説明も実装に合わせる。
remove_and_claim / claim_record / drain_and_claim の 3 か所に、 recorded への挿入と RECORDED_CAP による FIFO 間引きが同じ形で 書かれていた。1 か所だけ直し漏れて dedupe がずれるのを防ぐ。
bucket と kms_key は空文字を未設定として扱うが、ssm_param だけは
Some("") になり、init のたびに AWS SDK を初期化して空の名前で SSM を
呼んでいた。kms_key と同じく空文字を捨てる。
あわせて kms_key の値、空文字の扱い、0 値の拒否、相対パスの
ZANKYO_SPILL_DIR の無視を env 経路でテストする。
ZANKYO_DISABLED・バケット未設定・設定エラーの passthrough 判定で、 /opt/extensions/zankyo の agent は register せずに exit 0 していた。 Extensions API の契約では、Extension init 中に各 extension が register する 必要があり、init で extension が失敗すると Lambda は実行環境を再起動する （https://docs.aws.amazon.com/lambda/latest/dg/runtimes-extensions-api.html）。 AWS 公式 RIE の rapid/handlers.go の watchEvents も、shutdown 中でない extension の終了を exit code 0 でも AgentCrash（Extension.Crash）として扱う。 つまり緊急停止スイッチや設定ミスで関数の Init が失敗し、fail-open に反する。 passthrough でも SHUTDOWN だけを購読して register し、SHUTDOWN まで待つ。 INVOKE は購読せず、呼び出しごとの往復を増やさない。設定が壊れている 場合もあるので、ポーリングのノブは既定値を使う。 3 つのイベントループは wait_for_shutdown に集約し、drain_and_claim の 原子性の説明は呼び出し箇所へ移す。 本番の timeout 捕捉経路（run_agent の register → SHUTDOWN → .inflight 変換）と、 passthrough 3 条件での登録・待機を統合テストで検証する。
external extension がある構成（出荷する Layer は常にこれ）では、 shutdown ハンドルに解決しない future を入れていた。そのため in-flight を 持ったままランタイムが落ちると、wait_for_exit が返すハンドルを min(flush_budget, 1000ms) の間ずっと待っていた。 別プロセスの agent の完了はこのハンドルでは観測できないので、 ハンドル自体を持たず（None）、子の終了だけを待つ。
budget_shrinks_to_remaining_window は期限を 700ms 先に置いていたため、 now_ms の取得後に 500ms 以上止まると設定値へ倒れて失敗しえた。 期限を 5 秒先、設定値を 10 秒にして、残り 4.8 秒以下を確かめる。
passthrough が子の終了コードを返すこと、起動できないコマンドと空の argv を EX_OSERR に写すこと、spawn_via_proxy が子の AWS_LAMBDA_RUNTIME_API を proxy の listen ポートへ張り替えることを確かめる。
旧 TLS コネクタの除去（RUSTSEC-2026-0098/0099/0104/0258）と、 リリースゲート batch 1 の利用者に見える修正を載せる。版番号はリリース時に付ける。
成功呼び出しの /next と /response でも毎回 info ログが出ていた。既定のフィルタは info のため、利用者全員の CloudWatch Logs が呼び出し数に比例して増えていた。実機検証時のデバッグ用ログが残っていたもの。
Node.js ランタイムは /error・/init/error のボディでスタックトレースを trace キーで送る。stackTrace しか読んでいなかったため、Node.js 関数のレコードでは errorContext.stackTrace が常に欠け、init_error ではスタックが失われていた。stackTrace が無いときは trace を読む。
既定の denylist に cookie と cookies を足した。API Gateway・ALB・Function URL の Cookie ヘッダ、HTTP API v2 の cookies 配列、応答の Set-Cookie が平文で残っていた。
API Gateway・Function URL の body のように JSON を文字列化した値は、中のフィールドに denylist が効いていなかった。先頭が { か [ でパースできる文字列は中身を再帰で scrub し、denylist に一致したときだけ再シリアライズする。一致しなければ原文のままパターン置換だけを掛ける。
denylist に一致した配列は要素ごとに置き換え、配列の形を保つ。cookies 配列が文字列 "***" に変わると、replay でハンドラが元と別の例外で落ちるため。
パターン検出が数値型の値とキー名を検査しないことを README・SPEC・SECURITY.md に明記した。
- start_extension のログを internal extension に直し、独自 Layer 向けのフォールバックである旨を doc に書く - ProxyState.pending の doc と回収タスク panic のログを、起動時の回収タスクに合わせる - FailureType::Timeout の doc を、関数のタイムアウト以外の shutdown も含む意味に直す - Serialize だけの FailureRecord から、deserialize 用の serde default 属性を外す - mask_shape の重複した match 腕と到達しない unwrap_or をまとめる - handle() を通らない恒真テスト route_matching_shapes を削除する（経路は proxy_it.rs が担保）
- exit_code の wait 失敗テストの名前を実際の経路に合わせ、シグナル終了が 128+signal になることを確かめる - aws_access_key・bearer_token・phone・ipv4 の置換結果と patternsApplied への記録を確かめる
recorder_to が作る spill dir は /next のステージで実際に作られるのに、 明示的に消していたのは 3 テストだけで、アサーション失敗時にも残っていた。 テストごとの dir を Drop で消す SpillDir にまとめ、recorder_to から返す。
recover_spills は最後に空の spill dir を remove_dir していた。定期回収は 別ワーカーで走るため、ensure_dir と .part の作成の間に dir が消えると、 inflight ステージや spill の書き込みが ENOENT で失敗する。dir は残す。 あわせて、S3 が PUT を拒否する間は spill が残り、回復後の recover_spills が 同じキーへ同じレコードを再送して spill を消すことを統合テストで確かめる。
SSM の取得は、子ランタイムの起動と extension の登録より前に待つ。 既定値 10 秒は Lambda の Init 上限（10 秒）と同じで、NAT も VPC endpoint も 無い VPC では SSM を待つだけで Init の上限に達しうる。fail-open の設計に 合わせて 2 秒で諦め、env の設定で進む。README の表にも Init 上限に 含まれることを書く。 参照: https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html
失敗レコードの PUT は、呼び出し中の記録も SHUTDOWN 後のフラッシュも commit_staged が flush budget で打ち切る。put_timeout が効くのは spill 再送 だけである。それなのに README と Config の doc は PUT_TIMEOUT を「通常経路の PutObject 上限」と説明しており、失敗時の応答の遅れを調整したい利用者を 効かない設定へ導いていた。
- stage_timeout は SaveInput を組み立てて stage_save に任せる。
「spill が成功したときだけ inflight ステージを消す」規則を 1 か所にする
- spill の .part 経由の書き込みを write_atomic にまとめる。誰も使わない
write_inflight の bool の戻り値をやめる
- sanitize の trim_start_matches('.') を削る。直前の map で '.' は '_' に
なるため、常に何もしていなかった
- 削除済みの save を指す doc と、モジュールの責務の説明を実装に合わせる
- S3 モックで PutObject の SSE ヘッダを拾い、既定は AES256、 ZANKYO_KMS_KEY 指定時は aws:kms とキー ID が付くことを確かめる - 解析ロジックをテスト内で書き直していた upstream のテストを、 connection_named と strip_hop_by_hop を直接呼ぶテストに置き換える - proxy 経由の転送で、要求・応答の両方向から Connection 指名ヘッダと 固定の hop-by-hop が落ちることを統合テストで確かめる - ssm_overlay のテスト名の誤字（ssk_）を直す
replay・diff・redrive は、S3 レコード本文の functionName を invoke 先に していた。バケットに書ける別の関数が、他の関数を名乗るレコードを置くと、 運用者の権限でその関数へペイロードを投入させられた。 loadRecord で、キーの関数セグメントと本文の functionName を突き合わせる。 食い違うレコードは exit 4 で拒否する。--function の絞り込みはキーに効くので、 この突き合わせで --function との一致も保証される。
attachTo は zankyo/* 全体への PutObject を付けていた。同じバケットを
共有する関数は、互いの関数名の下にもレコードを置けた。CLI の突き合わせは
キーと本文の食い違いしか見ないため、キーごと偽った記録は防げなかった。
書き込み先を zankyo/{関数名}/* に限る。関数名は関数自身への Ref なので、
role の DefaultPolicy に入れると Function との循環依存になる。
関数ごとの独立した AWS::IAM::Policy として付ける。
以前は umask に従い 0644 などで作っていた。scrub 済みでもイベントの断片を 含むため、共有マシンでは他のユーザーから読めた。既存ファイルを上書きする ときは、そのファイルのモードを変えない。
- AwsClients.region は本番コードから読まれていなかった。フィールドを消し、
テストは S3/Lambda クライアントに --region が渡ることを確かめる形にした
- diff.ts の canonicalize と sortKeys は、テストからしか呼ばれていなかった
- fixtureJson の生テキストと base64 の分岐は同じ処理だったので 1 つにまとめた。
eventPayload の `?? {}` は、buildFixtureEvent が null を弾くため届かない
レコード不在を 2 に含めつつ「見つからない」を 4 としており、文の中で矛盾していた。実装と README に合わせ、レコードの不在・形式不正・再現できないレコードを 4 とする。
- prepack で build を実行する。files は dist だけで、dist は git の管理外の ため、clean clone から publish すると dist が無いか古いまま公開されえた - LICENSE を各パッケージに置く。以前は MIT の許諾文が tarball に入っていなかった - package.json に repository・homepage・bugs・keywords・author を足す。 cli/README.md の「リポジトリ直下の README」にもリンクを付ける
fakeS3 と fakeLambda / fakeLambdaSeq が、受け取った入力を配列に残すようにした。 ContinuationToken の受け渡し、--function の Prefix、getObject の Key、 diff が 2 つの alias を呼ぶこと、redrive の dry-run で invoke しないことと --confirm の送り先・ペイロードを確かめる。 あわせて、AWS 失敗の exit 3（list / fixture / replay）、replay の関数エラーの exit 1、ZANKYO_RECORD_MAX_MB を超えるレコードの exit 4 のテストを追加した。
getObject の失敗は exit 3 にしていたが、応答後に本文のストリームを読む transformToString の失敗は CliError に包んでいなかった。通信断などで bin.ts の既定の exit 2（引数・設定ミス）になり、README の exit code 表と 食い違っていた。getObject と同じメッセージで exit 3 に写す。
redrive は既定で dry-run のため、手順 6 のままでは関数を呼ばず、 成功応答を確かめられなかった。--confirm を付ける。 手順 4 の fixture --last は全関数で最新のレコードを選ぶため、手順 2 の timeout レコードを拾いうる。examples/README.md と同じく --function で絞る。
proxy.rs のコメントと README は、ボディを読むのは /next・/response・ /error・/init/error だけで、ほかの経路は触らず中継すると書いていた。 実際の handle() は経路判定の前に、全リクエストのボディを ZANKYO_MAX_BODY_KB まで読み、超えたら中継せず 413 を返す。 動作ではなく説明を直す。Runtime API で記録しない経路は /restore/next （ボディなし）と /restore/error（エラー情報）で、子プロセスから届く Extensions API・Telemetry API も小さな JSON しか送らない。Lambda が 受け付ける最大のボディは応答（同期 6 MB、ストリーミング 200 MB）で、 これは記録する /response 経路に届く。既定の 8192 KiB を超える正当な ボディは、記録しない経路には来ない。 記録しない経路（/restore/error）でも 413 になることを、既存の 上限超過テストに加えて固定する。
eventIsRawText・eventIsBase64 のコメントは、CLI が replay/redrive で原文を 送る・base64 をデコードして再送すると書いていた。実際の CLI は、fixture では 保存した形のまま書き出し、replay/diff/redrive では invoke せず exit 4 で止める。
SPEC.md の決定事項表は、SHUTDOWN の reason=timeout のときだけ in-flight イベントをフラッシュすると読めた。同じ SPEC の失敗の定義（41 行）と README、extension.rs の実装は、reason（timeout・failure・spindown）を 問わずに記録する。表をこの動作に合わせた。 同じ食い違いが、inflight.rs のモジュールコメント（SHUTDOWN（timeout）時）と build-layer.mts のコメント（SHUTDOWN（timeout）イベント）にもあったので直した。 動作は変えていない。
… に加える
THIRD_PARTY_LICENSES は、Cargo の normal 依存の crate だけを載せていた。
musl ターゲットのバイナリには、rustc が self-contained として持つ部品も
静的リンクされる。Rust 標準ライブラリ（compiler_builtins を含む）、
musl libc（libc.a と crt*.o）、LLVM の libunwind.a と crtbegin/crtend である。
これらの許諾文と著作権表示が、両アーキテクチャの zip に入っていなかった。
- scripts/licenses/ に、上流の原文をそのまま写した。版と写した元は次のとおり
- rust-lang/rust 1.98.1（rust-toolchain.toml の版）: COPYRIGHT・LICENSE-APACHE・
LICENSE-MIT・LICENSES/Unicode-3.0.txt（core の Unicode データ）・
library/compiler-builtins/LICENSE.txt
- musl v1.2.5 の COPYRIGHT（Rust 1.98.1 の musl-toolchain.sh の MUSL_VER）
- rust-lang/llvm-project 52ed14f（Rust 1.98.1 のサブモジュール、LLVM 22.1.8）の
libunwind/LICENSE.TXT と compiler-rt/LICENSE.TXT
- build-layer.mts の TOOLCHAIN_NOTICES が、写した元の URL を見出しにして、
crate と同じ重複排除で THIRD_PARTY_LICENSES に足す。zip のエントリ・mode・
mtime の扱いは変えていない
- rustc の版が 1.98.1 でなければ、ビルドの前に梱包を止める。Rust を上げたときに、
古い版の表示のまま梱包しないため
- CI の "check the layer zips" は、両 arch の THIRD_PARTY_LICENSES が、これらの
原文をそのまま含むことを確かめる。scripts/licenses/ から原文が消えても落ちる
- README の License 節と CHANGELOG の [Unreleased] に書いた
THIRD_PARTY_LICENSES の musl libc と LLVM の部品の表示は、rustc が self-contained として持つ版に合わせてある。cross build と cargo build （CI とリリースの手順）では、rustc がこれらをリンクする。一方、BUILDER には 任意のコマンド行を渡せた。cargo zigbuild のように、zig が持つ musl libc と CRT をリンクするビルダーでも Layer を作れ、その zip は表示と中身が食い違う。 - BUILDER は "cross build" と "cargo build" だけを受け付ける。ほかの値は、 rustc の検査や出力先の作成より前に、理由を出して止まる。未指定のときの 選び方（cross があれば cross build）は変えていない - ヘッダーと TOOLCHAIN_NOTICES のコメントから、zigbuild を使える旨の記述を外した - scripts/build-layer.test.mts を足し、pnpm test で実行する。偽の rustc・cargo・ cross を PATH に置き、BUILDER="cargo zigbuild" では何も起動せずに止まること、 cross build と cargo build は通ることを確かめる - README の License 節と CHANGELOG に書いた
THIRD_PARTY_LICENSES に載せた Rust の COPYRIGHT は、標準ライブラリの ファイルごとの表示と依存 crate のライセンスを COPYRIGHT-library.html に 置くと案内している。このファイルは、Layer にもリポジトリにもなかった。 - Rust 1.98.1 の rustc コンポーネントの share/doc/rust/COPYRIGHT-library.html を、 scripts/licenses/rust-1.98.1/ にそのまま写した。写した元は https://static.rust-lang.org/dist/rustc-1.98.1-x86_64-unknown-linux-gnu.tar.xz （channel-rust-1.98.1.toml の xz_hash と一致）。aarch64-apple-darwin と aarch64-unknown-linux-musl の rustc が持つものとも同じバイト列 （sha256 68129500…）。元の URL は RUST_LIBRARY_NOTICE に書いた - 両 arch の zip の share/licenses/zankyo/COPYRIGHT-library.html に置く。 mode は 644、mtime とエントリ順は他のエントリと同じ決定的な扱い。HTML なので THIRD_PARTY_LICENSES には混ぜず、案内の文を「隣のファイル」に直した - 梱包の前に、写しが rustc の sysroot の share/doc/rust/COPYRIGHT-library.html と 同じことを確かめる。Rust を上げて写しを更新し忘れると止まる - CI の "check the layer zips" は、両 arch の zip にこのエントリがあり、 scripts/licenses/ の原文と同じバイト列であることを確かめる - scripts/licenses/ は上流の原文なので、.gitattributes で whitespace の検査と GitHub の言語の集計から外した - テストに、写しが rustc のものと違うか無いときに止まることを加えた - README の License 節、CHANGELOG、sar/template.yaml のコメントに書いた
libunwind と crtbegin/crtend の表示（scripts/licenses/llvm-22.1.8/）は、 Rust が同梱する LLVM の版に合わせてある。梱包の前の検査は、rustc の版だけを 見ていた。Rust を上げたときに RUST_VERSION と rust-*/ だけを更新すると、 古い LLVM の表示のまま梱包できた。 - rustc -vV の release と LLVM version を、RUST_VERSION と LLVM_VERSION に 照らし合わせる。どちらかが違えば、ビルドの前に止まる - musl の版は rustc から読めないため、コメントで見直しを求める - テストに、rustc の版と LLVM の版がそれぞれ違うときに、何も作らずに止まることを 加えた - README の License 節に書いた
THIRD_PARTY_LICENSES は、crate のパッケージのルートにあるライセンスの ファイルだけを載せていた。crate が別のプロジェクトから取り込んだコードの 表示は、サブディレクトリにある。ring の LICENSE が案内する src/polyfill/once_cell/LICENSE-APACHE と LICENSE-MIT は、載っていなかった。 ring と aws-lc-sys の fiat-crypto、regex-syntax の Unicode の表の表示も 同じだった（COPYRIGHT-library.html と同じ種類の漏れ）。 - パッケージの中を再帰的にたどり、ライセンスのファイルをすべて載せる。 tests・benches・examples は、バイナリに入らないので見ない。順序は コードポイント順で、同じ依存からは同じテキストになる - テストに、偽の cargo metadata と、梱包に要るファイルだけを写したリポジトリで 梱包するものを加えた。zip のエントリ、COPYRIGHT-library.html のバイト列、 サブディレクトリの表示が載り tests/ の表示が載らないことを確かめる - README の License 節と CHANGELOG に書いた
…了させない external extension（agent）は、/register が 1 回失敗しただけで終了していた。 /event/next も、連続失敗が ZANKYO_EXT_MAX_POLL_FAILURES に達すると終了した。 どちらも終了コードは 0 だった。SHUTDOWN の前に終わった extension を、Lambda は 終了コードを問わず Extension.Crash とみなす。Init の失敗や、実行環境の 再起動につながる。記録する agent と記録しない agent の両方が同じだった。 - 登録は ZANKYO_REGISTER_TIMEOUT_MS の時間内で、ZANKYO_EXT_RETRY_MS の間隔で 再試行する。4xx（登録の拒否）と 500 は、送り直しても通らないのですぐに諦める。 1 回の要求の上限は残り時間とし、応答の無い要求は送り直さない - /event/next は SHUTDOWN まで再試行を続ける。諦めるのは、Lambda が 500 を 返したときと、Runtime API に接続できない状態が ZANKYO_EXT_MAX_POLL_FAILURES 回続いたときだけ。500 は、公式の Extensions API リファレンスが 「Container error. Non-recoverable state. Extension should exit promptly.」 と定める。403 などは再試行する（公式 RIE の実装では、接続が切れた後の /event/next は、次のイベントまで 403 で断られる） - 警告は連続失敗の 1・2・4・8… 回目だけに出す - SHUTDOWN の前に抜けたときは、agent の終了コードを 1 にする - /extension/init/error と /extension/exit/error は送らない。どちらも登録で 得る識別子が要り、終了する場面では API が使えない - テストを加えた。登録の一時的な失敗を再試行して SHUTDOWN まで進むこと。 /event/next の失敗が上限を超えて続いても、SHUTDOWN の前に終了しないこと。 登録の 403 と /event/next の 500 では、再試行せずに終了コード 1 で抜けること。 Runtime API に接続できないときは、上限の回数で諦めること - README・ARCHITECTURE・SPEC・CHANGELOG と、設定の説明を直した
external extension（agent）は、Extensions API の応答ボディをサイズの上限だけで 読んでいた。登録の上限時間は要求の送信とヘッダーの受信にしか効かず、エラー応答の ボディの読み取りには及ばなかった。相手がヘッダーだけ返してボディを閉じないと、 登録は ZANKYO_REGISTER_TIMEOUT_MS を過ぎても戻らずに Init を遅らせた。 /event/next では、エラー応答でも成功応答でも読み取りが止まり、再試行も SHUTDOWN の検知もできなくなった。 - ボディの読み取りは、ヘッダーの後 1 秒（EXT_BODY_TIMEOUT）で打ち切る。 localhost の Extensions API はヘッダーに続けてボディをすぐ送る - 登録では、残り時間が 1 秒より短ければ残り時間で打ち切る。エラー応答の ステータス（4xx の拒否・500）による判断はそのまま使い、ボディは空にする - /event/next で打ち切った応答は、ほかの一時的な失敗と同じく再試行する - テストを加えた。ボディを閉じないエラー応答で、登録が上限時間の内側で戻ること。 時間に余裕があれば再試行して登録できること。/event/next のエラー応答と成功応答の ボディが止まっても、記録する agent と記録しない agent が再試行して SHUTDOWN を 受け取ること
proxy は /next の応答ボディを、サイズの上限だけで読んでいた。ロングポーリングの ため /next の転送には時間の上限を付けておらず、ヘッダーの後のボディの読み取りも 無制限だった。Runtime API がヘッダーだけ返してボディを閉じないと、ランタイムの /next が止まったままになる。 - 応答ヘッダーまでは従来どおり無制限に待つ（AWS は /next にタイムアウトを 付けないよう求めている。これは応答が来るまでの待機の話で、ヘッダーの後の ボディには当たらない） - ヘッダーの後のボディは、ほかの経路の転送と同じ ZANKYO_FORWARD_TIMEOUT_MS で 打ち切り、ランタイムへ 502 を返す - ランタイムから届くリクエストボディには、時間の上限を付けない理由をコメントに 書いた。送り手は関数自身のランタイムで、止まって待たされるのはその要求だけに なる。時間で切ると、時間をかけて書き出す応答（RESPONSE_STREAM）を途中で切る - テストを加えた。上流の /next がボディを閉じなくても、上限時間で 502 を返し、 呼び出しを in-flight に残さないこと - README の設定表と、config.rs の説明を直した
README と SPEC の冒頭は、失敗した呼び出しを「確実に残し」と書いていた。実装は fail-open で、S3 に届かなかったレコードは /tmp に残して再送するが、/tmp にも 残せなかった場合や、再送の前に実行環境が破棄された場合は失われる。 - README と SPEC の冒頭を「S3 に記録し」に改めた - README の制限事項と SPEC に、記録がベストエフォートであることと、 失われる条件（/tmp にも残せない・再送前に実行環境が破棄される・spill の上限を 超える）を書いた - CHANGELOG の Security の項で、spill に退避したレコードは「後で再送される」と 書いていた箇所を、実行環境が残っていれば再送される、と改めた - README・SPEC・ARCHITECTURE・SECURITY・examples・CHANGELOG・パッケージの README・SAR テンプレートの説明を見直した。ほかに実装が守らない断定の表現は なかった
SSM の取得の上限時間は、取得の前に環境変数の値で決まる。以前は JSON の 値で Config を書き換えていたが、その値を使う処理は無く、効いていなかった。 ZANKYO_SSM_PARAM と同じく env だけのキー（ENV_ONLY_KEYS）とし、JSON に 書かれていたら warn を出して無視する。
README と ARCHITECTURE.md は「env → SSM → 既定値」と説明していたが、 実装は既定値・env・SSM の順に重ね、SSM の JSON にあるキーが優先する。 SSM を読む前に決まる env だけのキー・env の ZANKYO_DISABLED の真・ env の設定エラーも明記した。README の設定表には、SSM の取得に成功すれば SSM の ZANKYO_BUCKET だけで記録することを書いた。
README は ZANKYO_REGISTER_TIMEOUT_MS と ZANKYO_EXT_RETRY_MS だけを挙げていた。 実装（run_passthrough_agent）は ZANKYO_EXT_BODY_KB と ZANKYO_EXT_MAX_POLL_FAILURES も読まず、既定値を使う。README の本文と 設定表、ARCHITECTURE.md、CHANGELOG の該当項目に 4 つとも書いた。
ARCHITECTURE.md は上限・タイムアウト・間隔をコードへ埋め込まないとしていたが、 EXT_BODY_TIMEOUT（1 秒）など設定で変えない安全のための上限がある。 不変条件を「利用者が調整する動作ノブ」に狭め、9 つの定数を表にした。 extension.rs の名前の無い数値（4096 と 200）は ERROR_BODY_MAX_BYTES と SHUTDOWN_DEADLINE_MARGIN_MS にした（値は同じ）。表と proxy/src の定数は proxy/tests/docs_it.rs が突き合わせる。
…権限を書く config.rs の valid_spill_dir は、相対パスと空文字を warn を出して無視するが、 設定表に書いていなかった。SSM の JSON は construct が設定した ZANKYO_BUCKET・ ZANKYO_KMS_KEY も上書きし、construct が付ける権限はそのバケットとキーの分だけ であることも書いた。
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
目的
0.1.1 を公開する前に、リポジトリ全体の品質を上げます。v0.1.0 の後には、セキュリティの修正を含む 15 commit があり、未公開でした。また、construct の既定の SAR アプリケーション ID がプレースホルダのままでした。
内容
監査で確認した指摘を直しました。内訳は blocker 2・major 13・minor 72・info 20 です。利用者に影響する変更は、
CHANGELOG.mdの[0.1.1]にまとめました。主なものは次のとおりです。cookie・cookiesを足しました。bodyなど）の中のフィールドにも、denylist を適用します。attachToが付けるs3:PutObjectの範囲を狭めました。traceキーから、スタックトレースを取るようにしました。ZANKYO_SSM_TIMEOUT_MSの既定値を 2 秒に下げ、SSM の JSON では変えられないことを明記しました。attachToで、Layer と関数のアーキテクチャの食い違いを検出します。THIRD_PARTY_LICENSESを入れました。npm の tarball にも LICENSE を入れました。prepackを足しました。chore: lambda-zankyo 0.1.1 をリリースするで、RELEASING.md の手順 1（7 か所の版と CHANGELOG）を済ませました。検証
pnpm gate・cargo fmt --check・cargo clippy -D warnings・cargo test・pnpm audit --prodは、すべて exit 0 です。gpt-6-luna/ max で行いました。round 10 で PASS（findings なし）です。リリースの commit も、別途レビューしています。merge 後の手順（RELEASING.md）
zankyo-cdkとlambda-zankyoに公開します。