Auto-Await

Phase 17.5 で導入された Auto-Await は、Cloudflare binding 由来の async chain をビルド時に検出し、Workers runtime で必要な待機処理を自動で入れる仕組みです。アプリケーションコードは Ruby らしい同期形で書きます。

Before / After

Before（runtime 境界をアプリが意識していた頃）:

post '/users' do
  # runtime 境界に合わせた特別な書き方が必要だった
end

After（Auto-Await）:

post '/users' do
  database = Sequel.connect(adapter: :d1, d1: d1)
  result = database[:users].insert(name: 'foo')
  send_email.send(
    to: '...', subject: '...', text: '...'
  )
  'ok'
end

多くのケースで、ファイル先頭の magic comment やユーザー定義のメソッド名リストは不要になりました。推論不能なケース（metaprogramming、Hash 動的アクセスなど）は、明示的な wrapper/helper に切り出して型が見える形にするのが推奨です。

AsyncRegistry

gem 側で「これは async source」を宣言します:

CloudflareWorkers::AsyncRegistry.register_async_source do
  async_class 'Cloudflare::D1Database'
  async_class 'Cloudflare::KVNamespace'
  async_class 'Cloudflare::Email'

  async_accessor :env, :DB, 'Cloudflare::D1Database'
  async_accessor :env, :SEND_EMAIL, 'Cloudflare::Email'

  taint_return 'Sequel', :connect, 'Sequel::D1::Database'
  async_method 'Sequel::Dataset', :all
end

各 gem（homura-runtime、sinatra-homura、sequel-d1、sinatra-inertia）が自身の async source を登録します。プロジェクト固有の登録は lib/homura_async_sources.rb に集約できます。

診断モード

build 時にどの call を async 境界として扱ったかを確認できます:

CLOUDFLARE_WORKERS_AUTO_AWAIT_DEBUG=1 bundle exec homura build

制限とフォールバック

ケース	挙動
静的に型が決まる receiver	自動処理
同名 sync メソッド（`String#sub` 等）	誤検知なし（origin class で区別）
metaprogramming（`env.send(binding_name)`）	推論不能 → helper に切り出す
Hash 動的アクセス（`ctx[:mail].send(...)`）	推論不能 → 型が見える local 変数に出す

どうしても runtime 境界を直接扱う必要がある場合の低レベル escape hatch は残っていますが、通常のアプリ docs では使いません。