Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Automatically trace Cap'n Web RPC calls with Workers custom spans

オープン
  • 何か問題がありますか？
#269 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 5 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
api

調査の方向性

Start by tracing the common local dispatch path used by the HTTP batch and WebSocket transports, and review the Agents SDK Cloudflare tracing adapter at packages/agents/src/observability/tracing/cloudflare.ts. Determine how method and property calls can create Workers custom spans, remain active through asynchronous results, and fall back to a no-op runtime. Done means both transports are covered without application instrumentation and existing cross-runtime behavior is preserved.

索引モデルが issue の本文から書いたものです。

説明

enhancement

Problem

Cap'n Web RPC calls do not currently produce a span per method call. Workers automatically traces native Workers RPC calls, but calls using Cap'n Web's HTTP batch or WebSocket transports only have the surrounding runtime spans unless the application instruments every method itself.

Workers now exposes a custom spans API that libraries can use for this:

https://developers.cloudflare.com/workers/observability/traces/custom-spans/

What users have to do today

After enabling observability.traces.enabled, every RPC method that should appear in a trace must be wrapped manually:

import { tracing } from "cloudflare:workers";
import { RpcTarget } from "capnweb";

class Api extends RpcTarget {
  getUser(id: string) {
    return tracing.enterSpan("capnweb.rpc.getUser", async (span) => {
      span.setAttribute("user.id", id);
      return loadUser(id);
    });
  }
}

This is repetitive, easy to omit, and requires application code to know about a runtime-specific API. It also makes consistent span naming and attributes difficult across Cap'n Web applications.

Desired experience

Ideally, users enable Workers tracing and write no Cap'n Web-specific tracing code:

import { RpcTarget } from "capnweb";

class Api extends RpcTarget {
  getUser(id: string) {
    return loadUser(id);
  }
}

Cap'n Web could automatically create a server-side custom span around each incoming method call or property operation. The span should remain active until an asynchronous result settles so nested runtime operations such as fetch(), KV, D1, and user-created spans become children. Errors should still end the span correctly.

The behavior should degrade to a no-op on runtimes that do not expose the Workers tracing API, preserving Cap'n Web's cross-runtime support. The Agents SDK's Cloudflare tracing adapter is a useful example: it imports the cloudflare:workers namespace, detects tracing.startActiveSpan, and falls back to a no-op runtime without changing application behavior:

https://github.com/cloudflare/agents/blob/c076e4c9ff6cfb72931085226edfd3ee7965ac48/packages/agents/src/observability/tracing/cloudflare.ts

Design questions

  • Should automatic spans be enabled by default whenever Workers tracing is enabled, or exposed through a session option?
  • What span name and attributes should identify the method/property path and transport?
  • How should spans be bounded for long-lived WebSocket sessions, where calls arrive after the upgrade handler has returned?
  • Can the implementation instrument the common local dispatch path so HTTP batch and WebSocket transports behave consistently?
主要言語
TypeScript
スター
4k
フォーク
150
平均マージ
3日 12時間
マージ済み PR（30日）
2

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

cloudflare/capnweb のほかの issue

cloudflare/capnweb の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。