chore(worker): single-Worker topology; remove the Workflow binding, `entry.mjs`, the DO rate limiter and the `SELF` binding

Offen
#43 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
38/100
Issue-Typ
Refactoring
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
rust

Rechercherichtung

Start with crates/thrust-worker/wrangler.toml, wrangler.stage2.toml, and src/lib.rs, then trace the rate limiter through crates/thrust-adapters-cloudflare/src/lib.rs and crates/thrust-core/src/lib.rs. Review the named probes, contract tests, scripts, port comment, and architecture docs alongside the referenced ADRs. Done means the obsolete Workflow and rate limiter pieces are removed, the native binding and topology check are in place, and the listed contract and acceptance checks pass.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

area:app prio:p0 review:fable-2026-10-19

Context

crates/thrust-worker is already a single Worker: fetch, queue and scheduled in src/lib.rs:113, :166, :193, and two Durable Object classes, RateLimiterDo (src/durable.rs:26) and RoomDo (:79). Four pieces around it exist only for the role-split and workflow plans. main = "entry.mjs" (wrangler.toml:9) points at a 26-line JavaScript shim that defines the Workflow class ThrustWorkflow (entry.mjs:1-26). The [[workflows]] binding WORKFLOW is at wrangler.toml:80-83. The [[services]] binding SELF points the Worker at itself (wrangler.toml:75-77); two things use it, the service probe (src/probes.rs:87-92) and the shim's step.do callback (entry.mjs:21). The RATE_LIMITER Durable Object (wrangler.toml:45-55) sits behind DoRateLimiter (crates/thrust-adapters-cloudflare/src/lib.rs:187-223), and create_work_item calls it before every create (crates/thrust-core/src/lib.rs:235-243). wrangler.stage2.toml repeats all four (:52-62, :79-86).

Problem

  • ADR-0090 is still proposed, with Option 2 (role-split Workers) as the leading hypothesis (adrs/infra/0090-cloudflare-topology.md:38-40; Q-0090 open). FR-11 accepts Option 1 for P0 and the daily-use release: one Worker with fetch, queue, scheduled, static assets and placement. A collab Worker is added only when the P1 room lands.
  • FR-05 withdraws the WorkflowEngine port. That leaves no job for the shim, which is the only JavaScript in the Worker and the only live entry in the ADR-0006 non-Rust register (adrs/architecture/0006-runtime-language-and-framework.md:107, :111). Its exit plan, "when workers-rs ships a Workflow API", has no date (adrs/jobs/0071-workflow-port.md:122).
  • The DO limiter contradicts three accepted decisions. ADR-0033 accepted Option 1, the Workers Rate Limiting binding, in round 15 (adrs/api/0033-rate-limiting-and-api-keys.md:31). D-007 accepts per-location, approximate limits with 10 s or 60 s periods (DEVIATIONS.md:15). ADR-0082 round 25 introduces no DO class for rate limiting at P0 (adrs/storage/0082-cache-and-session-port-kv.md:35). Meanwhile it adds one DO round trip to every create (research/0004 §9, line 327). The port's doc comment still says the Cloudflare adapter is a Durable Object (crates/thrust-ports/src/lib.rs:213-214).

Proposal

  1. Delete entry.mjs and set main = "build/worker/shim.mjs" in wrangler.toml and wrangler.stage2.toml, as wrangler.memory.toml:3 already does. Remove the [[workflows]] and [[services]] blocks. Delete the service and workflow probes (src/probes.rs:87-143) and serde-wasm-bindgen (Cargo.toml:32), which only the workflow probe uses.
  2. Replace DoRateLimiter with an adapter over env.rate_limiter(..); workers-rs already supports the binding natively, as the ratelimit probe shows (src/probes.rs:54-64). Add a [[ratelimits]] binding for creates (for the contract cell, simple = { limit = 30, period = 60 }, matching RATE_LIMIT=30 in scripts/contract.sh:33). On Cloudflare the binding's configuration is the source of truth. The Worker root rejects any THRUST_RATE_WINDOW_SECS other than 10 or 60 at startup (ADR-0033 :33). A refusal maps to Limited { retry_after_secs: period }. The native set keeps MemoryRateLimiter in process.
  3. Remove RateLimiterDo (src/durable.rs:22-73) and the RATE_LIMITER binding. No deployed Worker carries the v1 migration (the Stage 2 Worker was deleted, wrangler.stage2.toml:3), so edit v1 to new_sqlite_classes = ["RoomDo"]. If one has been deployed by then, add a v2 migration with deleted_classes = ["RateLimiterDo"] instead. RoomDo stays as the P1 collab template.
  4. create_is_rate_limited_per_user (crates/thrust-contract-tests/tests/contract.rs:319-334) asserts an exact limit. The binding does not promise one: the deployed binding allowed 4 of 3 (tests/worker_only.rs:167-175). Use the target-agnostic bound the binding probe already uses. The first limit creates pass, a 429 with Retry-After appears within 2 × limit + 1 creates, and another member is unaffected. Move the exact check into a unit test of MemoryRateLimiter, and give the reason in the commit message (AGENTS.md rule 3, D-007).
  5. Set EXPECT_BINDINGS to 4 (scripts/contract.sh:40) and the bindings pass to 3 (scripts/stage2-contract.sh:49), and fix both headers. Update docs/src/architecture/infra.md:12-51, docs/src/architecture/app.md:84 and the port comment.

Acceptance criteria

  • entry.mjs is gone, and grep -nE 'workflows|\[\[services\]\]|RATE_LIMITER|RateLimiterDo|entry\.mjs' crates/thrust-worker/wrangler*.toml prints nothing.
  • grep -rn -e DoRateLimiter -e ThrustWorkflow crates docs/src prints nothing.
  • scripts/contract-all.sh is green on all 16 cells, and worker-cf bindings reports passed=4 expected=4.
  • create_is_rate_limited_per_user passes on worker-cf against the binding. Control: with the binding's limit raised above 2 × 30 + 1, it fails.
  • A topology check run by the deps CI job fails on any [[workflows]] or [[services]] block, or on a main other than build/worker/shim.mjs. It is shown failing on today's wrangler.toml.
  • ADR-0090 and ADR-0071 (round-29 notes) are cited in the PR. The ADR-0006 register no longer lists the Workflows shim as live.

References

  • Review: .agents/plans/contrail/reviews/2026-10-19-fable-architecture-review.md (FR-05, FR-11)
  • crates/thrust-worker/wrangler.toml:9, :45-55, :75-83; crates/thrust-worker/wrangler.stage2.toml:3, :52-62, :79-86
  • crates/thrust-worker/entry.mjs:1-26; src/probes.rs:54-64, :87-143; src/durable.rs:22-73; src/lib.rs:94
  • crates/thrust-adapters-cloudflare/src/lib.rs:187-223; crates/thrust-ports/src/lib.rs:207-218; crates/thrust-core/src/lib.rs:235-246
  • crates/thrust-contract-tests/tests/contract.rs:319-334; tests/worker_only.rs:162-220; scripts/contract.sh:13-14, :40; scripts/stage2-contract.sh:11, :49
  • ADR-0090 (round-29 note), ADR-0071 (round-29 note), ADR-0033 (round-29 note), ADR-0082, ADR-0006, ADR-0007; D-007; Q-0090, Q-0030.2
  • research/0004 §9 (DO limiter cost); research/0006 §13.5 (service-binding hop +2.3 to +2.8 ms)

Finding: FR-05, FR-11

Vorherrschende Sprache
Rust
Sterne
0
Forks
0
Ø Merge
1 Std. 35 Min.
Gemergte PRs (30 T.)
67

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus aRustyDev/thrust

Alle Issues in aRustyDev/thrust

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.