Question 1

なぜ Effect の RequestResolver.persisted は、staleWhileRevalidate のリフレッシュが失敗した後も、TTL が更新された古いデータを提供し続けるのですか？

Accepted Answer

これは Effect 4.0.5 のバグです（`main` でも依然として存在します）。`staleWhileRevalidate` を使用している場合、バックグラウンドリフレッシュの `runAll` がバッチ全体として失敗したとき（またはエントリを完了せずに成功したとき）、`persisted` は失敗を永続化する代わりに、古い保存値を新しい TTL で書き戻します。その結果、stale なエントリが復活し、無期限に延長され続けます。エントリごとの失敗は正しく保存されます。回避策：エフェクト全体を失敗させるのではなく、リゾルバーが各リクエストを個別に完了させるようにしてください。リゾルバー内でエラーをキャッチし、すべてのエントリを自分で失敗させます：

```ts
const resolver = RequestResolver.make<GetValue>((entries) =>
  Effect.catchAll(backendCall(entries), (err) =>
    Effect.sync(() => {
      for (const entry of entries) entry.completeUnsafe(Exit.fail(err))
    })
  )
)
```

エントリごとに完了させることで、失敗は `PersistenceStore.setMany` を介して永続化され、stale な値が書き戻されることはありません。上流での修正は effect-ts の issue #9583 で追跡してください。

Question 2

なぜ Effect の FiberMap.run / FiberHandle.run は、スコープが閉じられたときに置き換えられたファイバーのクリーンアップを待機しないのですか？

Accepted Answer

effect@4.0.5では、占有済みのキー/ハンドルに対して`FiberMap.run`（または`FiberHandle.run`、`set`、`runtime`）を呼び出すと、以前のファイバーを待機せずに中断し、コンテナから切り離します。スコープのファイナライザーはコンテナ内に残っているファイバーのみを待機するため、置き換えられたファイバーの中断クリーンアップ（例：`Effect.onInterrupt`）がまだ実行中であっても、スコープは閉じられてリソースが解放されます。`NodeRuntime.runMain`では、SIGTERMの後にそのクリーンアップが完了する前にプロセスが終了してしまうことさえあります。

回避策：`remove`/`clear`は中断の完了を待機するため、置き換える前に古いファイバーを明示的に削除して待機してください：

```ts
// FiberMap: 先にremoveしてからrun
yield* FiberMap.remove(map, "k")
yield* FiberMap.run(map, "k", newEffect)

// FiberHandle: 先にclearしてからrun
yield* FiberHandle.clear(handle)
yield* FiberHandle.run(handle, newEffect)
```

これにより、古いファイバーのクリーンアップが置き換えの開始前およびスコープのクローズ前に完了することが保証され、期待される解放順序（クリーンアップが外部リソースの解放より先に実行される）が復元されます。

effect

概要

README プレビュー

FAQ (2)

同类型项目

browser-use

puppeteer

manim

PaddleOCR