[Help wanted] Validate Worker quota under 100 concurrent calls — Cloudflare Workers KV atomicity test

[hoainho]

🌟 Before claiming this issue

Two quick steps before you open a PR:

1. ⭐ Star the repository — low-friction signal that you'll follow through
2. 💬 Comment I'll take this (or similar) below — prevents two contributors racing on the same issue

Full policy: CONTRIBUTING.md → How to claim. If a claim is older than 7 days with no PR, you can reclaim it politely.

---

Context

The Worker quota requirement worker-quota/spec.md "Concurrent writes do not lose increments" claims that 20 concurrent requests against a free-tier key result in counter equal to 20 exactly (no lost updates). This needs an independent reproducibility test with higher concurrency.

Where to look

• File: worker/src/quota.ts (created by task 3.6)
• The spec says 20 concurrent requests; we want 100 to truly stress the atomicity guarantee
• KV getWithMetadata + put is NOT atomic by default; needs explicit single-flight pattern (D1 atomic counter or Durable Object)

Expected outcome

• New test file worker/test/quota-concurrency.test.ts
• Test fires 100 concurrent incrementAndCheck calls against a fresh key in a real Cloudflare Workers preview environment
• Asserts: final counter equals exactly 100 (zero lost updates)
• Documents the implementation choice (D1 vs Durable Object vs other) and the latency cost

Estimated effort

M (3 to 6h)

How to claim

Comment "@hoainho I will take this" to claim. PR within 10 days or unclaimed.

Acceptance criteria

• Test passes on wrangler dev --remote mode (real KV/D1)
• Test is wired into CI via wrangler-action or manually-triggered workflow
• If atomicity guarantee cannot be met with current implementation, open a follow-up issue with the failure mode documented

[tranthequang]

Thanks for reporting this issue.

I may be able to prepare a focused PR for this, but I need a bit more implementation context first.

Could you please clarify:

1. Which file/module/page is affected?
2. Current behavior
3. Expected behavior
4. Reproduction steps/logs/screenshots if available

Once clarified, I can continue with a targeted fix.

[hoainho]

Hey @tranthequang thanks for jumping in and wanting to help!

I appreciate you asking for clarification — that's the right instinct here. Let me explain what's going on with this issue:

The TL;DR: this issue was auto-generated from planning/spec documents in the openspec/ directory. The worker/quota.ts file and the Cloudflare Workers test environment it describes don't exist yet in this repo — they're part of a planned MCP server feature that's still in the specification phase.

So the concurrency test this issue asks for would be testing code that hasn't been written yet. That's why the details in the issue body seem self-referential — it's a spec-to-be, not a description of existing code.

Two options if you'd like to contribute right now:

1. Pick a different issue — we have several well-scoped 'good first issue' and 'help wanted' issues that are actionable against the existing codebase. Check out perf: eliminate JSON.stringify in ReduxTab render hot path #32 (perf: eliminate JSON.stringify in ReduxTab render hot path), test: expand coverage to src/services/ (snapshot-builder, token-optimizer, ai-client) #33 (good first issue), or any of the help wanted issues.

2. Start implementing the Worker quota feature — if you're interested in working with Cloudflare Workers + KV, you could kick off the implementation itself. The spec is at openspec/changes/mcp-server-v1/specs/worker-quota/spec.md. Then the concurrency test would follow naturally.

Let me know which direction you prefer and I'll help unblock you either way!