ewang
90d · built 2026-09-08
Performance
What ewang shipped in the selected window, measured in ETV, and how it compares with the 90 days before it.
Effective capacity
−0.1engineers
delivers like 0.9 (0.9x pre-AI)
Output (ETV)
9.7ETV
−16.9% vs 11.7 prior
Features share
61.3%
+1.9 pp vs prior window
Fixes share
12.4%
−14.0 pp vs prior window
Work mix
61.3% Features7.7% Maintenance17.5% Tests1% Docs12.4% Fixes
23 commits over 90 days, ending 2026-09-08.
Daily performance
Daily ETV, stacked by Features, Maintenance, Tests, Docs and Fixes.
Repository spread
Where this developer's commits land. Concentrated work (top1 > 80%) vs polymath spread (top1 < 30%).
Most impactful commits
Top 10 by ETV in the last 90 days.
- 2.5ETVShare health across load-balancing selectors Add grouped selectors with asynchronous bounded rebuilds and shared active health across backend views.github.com-cloudflare-pingora · d6257c16 · 2026-07-09
- 1.1ETVlet a reader stop waiting when the writer names its fill A reader coalescing behind a cache lock cannot act on anything the writer learns after the reader committed to waiting, so it waits out the full lock age even once the fill is known to be no use to it. A circular dependency can otherwise leave two participants each waiting on the lock held by the other. A writer now describes its fill with opaque `u64` tokens via `WritePermit::publish`, and a reader names the fills it cannot use in a `FillInterest` on its `CacheKey`. On a match the reader alone stops waiting; the lock status is untouched and other readers keep coalescing. Matching is integer comparison done by the cache, so no application code runs on the writer's task, and one mutex covers both published tokens and the waiter registry, making the check-then-register race impossible rather than merely unlikely. Only matching readers are woken. Each publish replaces the last: a writer that moved on is no longer doing what it said, and a reader giving up over an abandoned attempt would lose its caching for nothing. Replacing nothing with nothing cannot wake anyone, so it skips the lock rather than taking it on every upstream request. The reason rides on the token rather than the set, since a key carries one `FillInterest` and independent parts of an application share it. It travels as `NoCacheReason::Custom`, so no caller-specific cause enters the enum. `cache_lock_wait` now returns `LockWaitOutcome` rather than `LockStatus`. `LockStatus` is the lock's *shared* state, stored in an atomic and observed by every coalescing reader, so it cannot carry a payload; what happened to one reader's wait is per-reader and never stored. Separating them lets `Abandoned { reason, token }` carry its cause in the value, so there is no separate question of whether the cause was recorded, and it makes `LockStatus::Waiting` unrepresentable as a wait result -- retiring the `panic!("impossible LockStatus::Waiting")` in `handle_lock_status`. This also addresses the TODO in `handle_lock_status`, which attributed every `GiveUp` to `CacheLockGiveUp` ("the writer found the asset uncacheable") regardless of cause.github.com-cloudflare-pingora · a0a88a31 · 2026-08-04
- 0.9ETVShare backends across load-balancing selectorsgithub.com-cloudflare-pingora · 8f9f44f5 · 2026-07-09
- 0.8ETVMake HTTP/1 response header reads cancel safe Previously, long request body reads in the proxy state machine could interrupt an upstream response header read after it had already consumed partial bytes. Dropping that future lost those bytes, so the next response read could resume mid-header and report a spurious read error.github.com-cloudflare-pingora · 7166d81e · 2026-07-01
- 0.6ETVAdd downstream TLS handshake offloadgithub.com-cloudflare-pingora · 8aeef341 · 2026-06-30
- 0.6ETVAvoid cloning cache keys during purgegithub.com-cloudflare-pingora · e2aa5632 · 2026-08-14
- 0.6ETVAdd deferred cache admission policy hookgithub.com-cloudflare-pingora · 11b57649 · 2026-07-10
- 0.5ETVTighten Custom proxy task defaults and add coveragegithub.com-cloudflare-pingora · 9c16af9c · 2026-06-24
- 0.4ETVClose unclaimed inherited listening sockets on graceful upgrade During a zero downtime upgrade, unclaimed inherited fds were left open and transferred to later generations. With SO_REUSEPORT these sockets can black-hole connections because they remain active without an acceptor. Track complete service listen-address sets and close inherited fds not claimed after services are registered. If any service cannot report a complete set, skip cleanup. Adds coverage for both bootstrap paths and custom services.github.com-cloudflare-pingora · f82478ae · 2026-07-23
- 0.3ETVpingora-proxy: reject malformed Connection nominations of protected headers Validate each Connection nomination against the HTTP `token` grammar (RFC 9110 §5.6.2) before checking it against the protected set (Host, X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Proto), instead of comparing raw bytes and silently dropping tokens that fail to parse as a header name. Those two paths were mutually exclusive, so a decorated nomination like `Connection: "X-Forwarded-For"` matched no protected literal, was dropped, and the request proceeded instead of being rejected. Validating the grammar directly makes the reject independent of how permissive the header-name parser is. A protected header can never actually be stripped via nomination either way (a decorated token names a distinct header), so this hardens the fail-closed reject rather than fixing a header-stripping vulnerability. Add `HttpUpstreamRequestPolicy::reject_malformed_connection_nominations` (default true) to opt into tolerating malformed nominations as distinct literal fields, matching nginx/Envoy/Caddy. Exact protected and pseudo-header nominations are rejected either way.github.com-cloudflare-pingora · ca23f166 · 2026-07-23