|  | 
|  | 1 | +# AGENTS Guidelines for This Repository | 
|  | 2 | + | 
|  | 3 | +This repository contains Chainbench, a blockchain infrastructure benchmarking tool built on Locust. When working on the project interactively with an agent (e.g. the Codex CLI) please follow the guidelines below for efficient development and testing. | 
|  | 4 | + | 
|  | 5 | +## 1. Use Headless Mode for Development Testing | 
|  | 6 | + | 
|  | 7 | +* **Always use headless mode** with short test durations during development. | 
|  | 8 | +* **Start with minimal load** (few users, low spawn rate) to validate changes. | 
|  | 9 | +* **Do _not_ run long-duration tests** during agent development sessions. | 
|  | 10 | +* **Use `--autoquit`** flag to ensure tests terminate properly. | 
|  | 11 | + | 
|  | 12 | +Example test command: | 
|  | 13 | +```bash | 
|  | 14 | +poetry run chainbench start --profile evm.light --users 5 --workers 1 --test-time 30s --target https://test-node --headless --autoquit | 
|  | 15 | +``` | 
|  | 16 | + | 
|  | 17 | +## 2. Keep Dependencies in Sync | 
|  | 18 | + | 
|  | 19 | +If you add or update dependencies: | 
|  | 20 | + | 
|  | 21 | +1. Use Poetry to manage dependencies: `poetry add <package>` or `poetry add --group dev <package>`. | 
|  | 22 | +2. Run `poetry lock --no-update` to update the lock file. | 
|  | 23 | +3. Install updated dependencies with `poetry install`. | 
|  | 24 | +4. Verify compatibility with Python 3.10+ as specified in the project. | 
|  | 25 | + | 
|  | 26 | +## 3. Coding Conventions | 
|  | 27 | + | 
|  | 28 | +* Follow Black formatting (120 character line length). | 
|  | 29 | +* Use isort for import sorting (Black-compatible profile). | 
|  | 30 | +* Follow Flake8 linting rules (E203 ignored for Black compatibility). | 
|  | 31 | +* Use type hints where appropriate. | 
|  | 32 | +* Keep MyPy checks passing. | 
|  | 33 | + | 
|  | 34 | +## 4. Code Quality Checks | 
|  | 35 | + | 
|  | 36 | +Before completing any task, run these quality checks: | 
|  | 37 | + | 
|  | 38 | +| Command                  | Purpose                                    | | 
|  | 39 | +| ------------------------ | ------------------------------------------ | | 
|  | 40 | +| `poetry run black .`     | Format code to project standards          | | 
|  | 41 | +| `poetry run isort .`     | Sort imports                               | | 
|  | 42 | +| `poetry run flake8`      | Run linting checks                        | | 
|  | 43 | +| `poetry run mypy .`      | Run type checking                         | | 
|  | 44 | + | 
|  | 45 | +Or use pre-commit hooks: | 
|  | 46 | +```bash | 
|  | 47 | +poetry run pre-commit run --all-files | 
|  | 48 | +``` | 
|  | 49 | + | 
|  | 50 | +## 5. Testing Guidelines | 
|  | 51 | + | 
|  | 52 | +Test changes progressively: | 
|  | 53 | + | 
|  | 54 | +1. **Unit testing**: Test individual user classes and methods | 
|  | 55 | +2. **Profile validation**: Verify profiles load correctly | 
|  | 56 | +   ```bash | 
|  | 57 | +   poetry run chainbench list profiles | 
|  | 58 | +   ``` | 
|  | 59 | +3. **Short headless tests**: Run brief tests with minimal load | 
|  | 60 | +4. **Method discovery**: Test endpoint compatibility | 
|  | 61 | +   ```bash | 
|  | 62 | +   poetry run chainbench discover https://test-node --clients geth | 
|  | 63 | +   ``` | 
|  | 64 | + | 
|  | 65 | +## 6. Profile Development | 
|  | 66 | + | 
|  | 67 | +When creating or modifying profiles: | 
|  | 68 | + | 
|  | 69 | +* Place custom profiles in appropriate subdirectories. | 
|  | 70 | +* Follow existing profile structure and conventions. | 
|  | 71 | +* Include docstrings explaining profile purpose. | 
|  | 72 | +* Test with small data sizes first (`--size XS`). | 
|  | 73 | +* Validate against multiple node types when applicable. | 
|  | 74 | + | 
|  | 75 | +## 7. Working with Test Data | 
|  | 76 | + | 
|  | 77 | +* Start with smallest data size (`--size XS`) for development. | 
|  | 78 | +* Use `--use-latest-blocks` for nodes with limited history. | 
|  | 79 | +* Consider using `--ref-url` for test data generation from a reference node. | 
|  | 80 | +* Monitor memory usage with larger data sizes. | 
|  | 81 | + | 
|  | 82 | +## 8. Development Workflow | 
|  | 83 | + | 
|  | 84 | +1. Make changes to source code | 
|  | 85 | +2. Run formatting: `poetry run black . && poetry run isort .` | 
|  | 86 | +3. Run linting: `poetry run flake8` | 
|  | 87 | +4. Run type checking: `poetry run mypy .` | 
|  | 88 | +5. Test with minimal profile first | 
|  | 89 | +6. Gradually increase complexity and load | 
|  | 90 | + | 
|  | 91 | +## 9. Useful Commands Recap | 
|  | 92 | + | 
|  | 93 | +| Command                                           | Purpose                               | | 
|  | 94 | +| ------------------------------------------------- | ------------------------------------- | | 
|  | 95 | +| `poetry install`                                  | Install all dependencies              | | 
|  | 96 | +| `poetry run chainbench --help`                   | Show all available commands           | | 
|  | 97 | +| `poetry run chainbench list methods`             | List supported RPC methods            | | 
|  | 98 | +| `poetry run chainbench list profiles`            | List available profiles               | | 
|  | 99 | +| `poetry run chainbench list shapes`              | List load pattern shapes              | | 
|  | 100 | +| `poetry run chainbench discover <url>`           | Discover available methods            | | 
|  | 101 | + | 
|  | 102 | +## 10. Safety Reminders | 
|  | 103 | + | 
|  | 104 | +* **Test against test/dev nodes first** before production nodes. | 
|  | 105 | +* **Monitor target node health** during benchmarks. | 
|  | 106 | +* **Use appropriate rate limits** to avoid overwhelming nodes. | 
|  | 107 | +* **Start with light profiles** before heavy ones. | 
|  | 108 | +* **Keep test durations short** during development. | 
|  | 109 | + | 
|  | 110 | +--- | 
|  | 111 | + | 
|  | 112 | +Following these practices ensures reliable development, prevents overwhelming blockchain nodes, and maintains code quality. Always prioritize controlled testing and gradual load increases when benchmarking infrastructure. | 
0 commit comments