Edge Forms

English

日本語

English

日本語

Appearance

Japanese source

The original specification and guide are authored in Japanese. The Japanese route contains the same source text; this English route is a reading aid, not a separate translation or an implementation-availability claim.

Version-fixed Form specification

This version-fixed URL serves the Japanese normative source. Read the exact source. Publication does not imply Host or provider support.

WorkerDeployment 0.7.0 ​

このFormはModuleWorker 0.3.0一つの有効な WorkerVersion 0.5.0または WorkerVersion 0.6.0または WorkerVersion 0.7.0または WorkerVersion 0.8.0の集合を選ぶ。forms.takoform.com/v2の Resourceであり、公開endpointやcronそのものを作らない。複数Versionへの配分は新たな イベントを選ぶ規則であって、進行中の実行、Actorの永続store、Workflowの履歴を移行しない。

入力と参照 ​

specはworkerとversionsだけを必須とする。workerはModuleWorker 0.3.0の {"resourceUid":string}参照である。versionsは1〜8件の {"workerVersion":{"resourceUid":string},"weight":integer}の配列で、 weightは1〜10000 basis point、総和は正確に10000とする。同じVersion UIDを二度 書けず、0 weightは省略で表す。配列順は選択確率に影響しない。既定値はない。 specと全入れ子の未知キー、null、小数、負数、範囲外、重複を拒否する。秘密入力はない。 同一specの比較ではversionsをVersion UID順の集合として扱い、配列順とobjectのキー順は 無視する。同じUID・weightの全組が等しければ同一specであり、weightの変更は更新である。

全トラフィックを一版へ割り当てるspecの例（UIDは説明用）:

json
{
  "worker": { "resourceUid": "worker-uid" },
  "versions": [
    { "workerVersion": { "resourceUid": "version-uid" }, "weight": 10000 }
  ]
}

Hostは各参照が同じHost・Spaceに存在し、要求者が利用を認可され、Form URLが上記の版に 完全一致することを副作用前に検証する。Versionは0.5.0、0.6.0、0.7.0、0.8.0の上記exact URLだけを許し、 いずれの版も別版へ変換・再解釈しない。各Versionのspec.worker.resourceUidはこの Deploymentのworker.resourceUidと一致しなければならない。Version UIDを保存し、名前や 「最新」から再解決しない。一つのWorkerに有効なDeploymentは高々一つである。 このWorkerDeployment 0.7.0と旧WorkerDeployment 0.4.0、0.5.0、0.6.0を跨いで同じsingle-active所有を検証し、 別Formだからという理由で同時に有効化してはならない。先に旧Deploymentを削除してから 新しいDeploymentを作る。これは既存UIDの自動Form移行ではない。

選択と成立条件 ​

Hostは新たなHTTP要求、scheduled、queue、Actor event、Workflowの新しい実行contextを受理する 時点の有効な配分からVersionを一つ選び、その一つを当該invocationの終了まで固定する。 配分はbasis pointの比率であり、個別requestに決定的なhash結果や短期の正確な件数を保証しない。 Worker Versionを選択できなければ別のVersionへ黙ってfallbackしない。Clientに見える失敗は 該当するhandler/Binding契約による。新しい配分は受理後の実行にだけ適用し、既存のHTTP stream、 Actor event、Workflow contextを途中で切り替えない。Actorの次のeventとWorkflowの次の retry/wakeは、その時点の配分を再選択できる。

ready:trueとして有効化する前にHostは全weighted Versionの指定済みbundle、handler、 asset、Binding、必要な秘密を確認する。添付されたEndpoint/CustomDomainまたは このWorkerを宛先とするservice Bindingがある場合、到達し得る全Versionは 宣言・export済みfetchか検証済みassetsのいずれかでHTTP要求へ応答できなければならない。 cron/queue consumerが要求するhandlerは、到達し得る全Versionが宣言・exportしなければ ならない。添付後のDeployment作成・更新、または後からのAttachment作成・更新でも 同じ全weighted Versionの条件を検証し、欠ける構成を有効にしてはならない。 同じWorkerを参照する削除未完了のActorNamespaceとDurableWorkflow（作成Operationを 受理済みのものを含む）の全classNameを各Versionが正しいprototype ABIで提供しなければ ならない。Namespace/Workflowの作成と、このDeploymentの作成・配分更新は、受理済みで 未完了のOperationを含めて整合性を保つ。後から作るNamespace/Workflowは現在の 有効配分を不適合にしてはならず、その作成を409 dependency_conflictで副作用前に拒否する。 両方が成功すると不適合な配分が有効になる組合せを認めない。Hostはこの整合性を 実装方法に依存せず守る。作成・更新の受理後に並行変更との衝突が確定した場合も、 不適合な配分を有効化せず、その受理済みOperationの結果と残存効果を共通Host API v2に 従って報告する。受理済みOperationを後からHTTPの事前拒否へ置き換えない。 Workflowのstep name・効果・出力について新旧コードの履歴互換性は作者の責任であり、Hostは 既知の不整合を検出したら有効化を拒否し、検証できないことを互換性の証明として扱わない。 Hostは移行・履歴書換え・Actor store初期化で不整合を隠さない。参照先の後続削除や秘密消失で Readyが崩れたら新規受理を拒否し、残存状態を観測可能にする。

状態と操作 ​

未観測のobservedは {}。確認済みならready:boolean、active:boolean、 selectedVersions（{"resourceUid":string,"weight":integer}の配列）を返す。 active:trueは、このDeploymentがそのWorkerの新しいinvocationの選択元であることを表す。 readyは有効化可能性の観測であり、各requestや外部到達性の成功保証ではない。 observedAt/observedGenerationは共通APIの時点を示す。outputは {}。

  • 作成では参照と条件を検査し、一つのWorkerの有効配分として原子的に設置する。別の有効 Deploymentがある場合は置換せず拒否する。依存先が準備中なら受理したOperationは状態を 明示して待つことができるが、Readyでない配分へトラフィックを流さない。
  • 取得は最後に確認した配分と状態を返す。管理記録がある間は実行先の一時的な不在を 404に置き換えない。
  • 更新はspec全体を置換する。workerは不変で、変えるには別Deploymentを作る。 versionsは全件指定し、Hostは新集合を検証してから一度に切り替える。途中の部分配分を 公開しない。同一specの新しいキーのPUTも新しいOperation/generationで再照合する。 旧weightから外れたVersionには切替後の新規invocationを割り当てない。既存contextは 固定Versionで完了できるが、切替から15分を超えて残るcontextはHostが取消し、streamを 閉じ、childの物理的退役を確認する。この退役は新配分の有効化を妨げないが、古いVersionの 削除は退役が済むまで拒否する。Host障害時は所有記録から再開し、退役未確認を完了扱いしない。
  • 削除はまず新たなHTTP要求・scheduled・queue・Actor event・Workflow contextの選択を閉じる。 既存invocationには取消signalを送り、HTTP body/Actor upgrade予約とHost所有streamを止め、 child実行の物理的退役と古いownerのfenceを確認してから成功にする。Promise rejectionだけを 退役の証明としない。Hostが確認できない間はOperationを未確定として照合を続ける。 削除後はDeploymentなしでActor alarm/socket callbackやWorkflow wakeを新規配送しない。 Actorのstore・alarm・socket identity、Workflow instance・履歴は各Resourceに残すが、 旧Version UIDへのlive context参照は残さない。Worker/Versionや添付先Resourceを連鎖削除しない。

結果が不明な作成・更新・削除は元のIdempotency-Keyと要求を再送し、Operationと実行先を 照合する。タイムアウトから成功・失敗を推定して別のDeploymentを作らない。 参照先の所有者は参照先FormとHostであり、Deploymentはそのコードやdataを所有しない。 未知フィールドを受け入れる拡張や意味の変更には新しいForm URLを使う。

通常の後始末は、まずendpoint・cron・queue consumer等の入口を削除し、次にこのDeploymentを 削除して実行を退役させ、不要なVersionを削除し、そのVersionのBinding参照が消えてから ActorNamespace/Workflowを削除し、最後にWorkerを削除する。Namespace/Workflowの休眠dataを 消すのは各Resourceの明示的なDELETEであり、Deployment DELETEの連鎖副作用ではない。

WorkerVersion 0.6.0、0.7.0、0.8.0のcontainerBindingsはContainerのexact UID/認可/routeを検証してから 選択可能にする。新規Container callのgeneration選択と30秒drainはContainer本文に従い、 このDeploymentのWorker contextの15分退役期限で延長しない。 Deploymentの削除はContainerへの新規callerを閉じて残存I/Oを取消するが、Containerそのものや その独立dataを連鎖削除しない。Binding依存はVersionの明示DELETEまで残る。

本版が受理するVersionのForm URLは、上記の0.5.0、0.6.0、0.7.0、0.8.0の四つだけである。 一つの配分に異なる対応版を含めても、Version UIDごとの受理済みForm、Binding参照、 実装identity、closure digestとnative実行内容を保持する。WorkerVersion 0.7.0と0.8.0のbucketBindingsは 封じた参照先ObjectBucket 0.2.0または0.3.0に従い、旧Versionや旧bucketを未申告長対応へ 読み替えない。新しい配分での本文操作も当該ObjectBucketのEOF・確定・取消し規則に従う。 実行結果不明の書込に必要な所有をtimeoutから解放済みと推定しない。 WorkerVersion 0.8.0のcontainerBindingsは封じた参照先Container 0.1.0または0.2.0に従い、 0.1.0の参照を0.2.0の秘密・image index・早期response規則へ読み替えない。 Deployment 0.4.0、0.5.0、0.6.0の定義、既存のOperationと選択済み実行内容は変更しない。