address review: clarify eth_newFilter is polling not subscription, acknowledge existing violations
This commit is contained in:
parent
b2bb28f1b9
commit
92ede4c7b7
1 changed files with 2 additions and 2 deletions
|
|
@ -40,9 +40,9 @@ See [docs/dev-environment.md](docs/dev-environment.md) for restart modes, ports,
|
||||||
## Engineering Principles
|
## Engineering Principles
|
||||||
These apply to ALL code in this repo — contracts, tests, scripts, indexers, frontend.
|
These apply to ALL code in this repo — contracts, tests, scripts, indexers, frontend.
|
||||||
|
|
||||||
1. **Never use fixed delays or `waitForTimeout`** — subscribe to events instead. Use `eth_newFilter`/`eth_subscribe` for on-chain events, DOM mutation observers for UI changes, callback patterns for async flows. Even if event-driven code takes more effort, it is always the right answer.
|
1. **Never use fixed delays or `waitForTimeout`** — react to actual events instead. Use `eth_subscribe` (WebSocket) for on-chain push notifications, `eth_newFilter` + `eth_getFilterChanges` for on-chain polling, DOM mutation observers or Playwright's `waitForSelector`/`waitForURL` for UI changes, callback patterns for async flows. Even if event-driven code takes more effort, it is always the right answer.
|
||||||
2. **Never use hardcoded expectations** — dynamic systems change. React to actual state, not assumed state. Don't assert a specific block number, token amount, or address unless it's a protocol constant.
|
2. **Never use hardcoded expectations** — dynamic systems change. React to actual state, not assumed state. Don't assert a specific block number, token amount, or address unless it's a protocol constant.
|
||||||
3. **Event subscription > polling > fixed delay** — if there is truly no way to subscribe to an event, polling with a timeout is acceptable. A fixed `sleep`/`wait` is never acceptable.
|
3. **Event subscription > polling with timeout > fixed delay** — prefer true push subscriptions (`eth_subscribe`, WebSocket, observers). When push is unavailable (e.g. HTTP-only RPC), polling with a timeout and clear error is acceptable. A fixed `sleep`/`wait`/`waitForTimeout` is never acceptable. Existing violations should be replaced when touched.
|
||||||
|
|
||||||
## Before Opening a PR
|
## Before Opening a PR
|
||||||
1. `forge build && forge test` in `onchain/` — contracts must compile and pass.
|
1. `forge build && forge test` in `onchain/` — contracts must compile and pass.
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue