|
2 | 2 |
|
3 | 3 | ## Arguments |
4 | 4 |
|
5 | | -$ARGUMENTS - The library name to test (e.g., aiohttp, django, fastapi, flask, grpc, httpx, psycopg, psycopg2, redis, requests, sqlalchemy, urllib, urllib3) |
| 5 | +$ARGUMENTS - The library name, optionally followed by focus context. |
| 6 | + |
| 7 | +**Format**: `<library> [focus on <area>]` |
| 8 | + |
| 9 | +**Examples**: |
| 10 | + |
| 11 | +- `/bug-hunt redis` — broad bug hunting across all redis functionality |
| 12 | +- `/bug-hunt redis focus on pub sub interactions` — prioritize pub/sub patterns |
| 13 | +- `/bug-hunt psycopg2 focus on async cursors and connection pooling` — prioritize those areas |
| 14 | + |
| 15 | +**Parsing**: The first word is always the library name. Everything after it is the optional focus context. |
6 | 16 |
|
7 | 17 | ## Library-to-GitHub-Repo Mapping |
8 | 18 |
|
@@ -48,11 +58,15 @@ Each library has a single e2e-tests directory (no ESM/CJS variants): |
48 | 58 |
|
49 | 59 | ## Phase 0: Environment Setup |
50 | 60 |
|
51 | | -### 0.1 Validate the library argument |
| 61 | +### 0.1 Parse and validate the arguments |
| 62 | + |
| 63 | +Extract the library name (first word) and optional focus context (remaining words) from the arguments. |
52 | 64 |
|
53 | 65 | The library must be one of: aiohttp, django, fastapi, flask, grpc, httpx, psycopg, psycopg2, redis, requests, sqlalchemy, urllib, urllib3. |
54 | 66 |
|
55 | | -If the argument is invalid, list the valid options and stop. |
| 67 | +If the library is invalid, list the valid options and stop. |
| 68 | + |
| 69 | +If focus context is provided, it will guide Phases 1 and 2 to prioritize that area of the library's functionality. |
56 | 70 |
|
57 | 71 | ### 0.2 Docker Setup (Claude Code Web only) |
58 | 72 |
|
@@ -101,48 +115,56 @@ git checkout -b bug-hunt/<library>-$(date +%Y-%m-%d) |
101 | 115 |
|
102 | 116 | ## Phase 1: Develop Understanding |
103 | 117 |
|
| 118 | +**If focus context was provided**, prioritize your analysis around that area. For example, if the focus is "pub sub interactions", concentrate on pub/sub-related code paths in the instrumentation, tests, and package source. |
| 119 | + |
104 | 120 | ### 1.1 Analyze the Instrumentation Code |
105 | 121 |
|
106 | 122 | Read the instrumentation code at: |
107 | 123 |
|
108 | 124 | ``` |
109 | | -drift/instrumentation/$ARGUMENTS/instrumentation.py |
| 125 | +drift/instrumentation/<library>/instrumentation.py |
110 | 126 | ``` |
111 | 127 |
|
112 | 128 | Also check for any additional files in the same directory: |
113 | 129 |
|
114 | 130 | ``` |
115 | | -drift/instrumentation/$ARGUMENTS/ |
| 131 | +drift/instrumentation/<library>/ |
116 | 132 | ``` |
117 | 133 |
|
118 | 134 | Identify: |
119 | 135 |
|
120 | 136 | - Which functions from the package are patched/instrumented |
121 | 137 | - The patching strategy (what gets wrapped, when, and how) |
122 | 138 | - Any helper modules or utilities used |
| 139 | +- **If focus context provided**: Which patches relate to the focus area, and what's missing? |
123 | 140 |
|
124 | 141 | ### 1.2 Analyze Existing E2E Tests |
125 | 142 |
|
126 | 143 | Review the test files: |
127 | 144 |
|
128 | | -- `drift/instrumentation/$ARGUMENTS/e2e-tests/src/app.py` — all test endpoints (Flask/FastAPI/Django app) |
129 | | -- `drift/instrumentation/$ARGUMENTS/e2e-tests/src/test_requests.py` — which endpoints are called |
130 | | -- `drift/instrumentation/$ARGUMENTS/e2e-tests/entrypoint.py` — test orchestration and setup |
| 145 | +- `drift/instrumentation/<library>/e2e-tests/src/app.py` — all test endpoints (Flask/FastAPI/Django app) |
| 146 | +- `drift/instrumentation/<library>/e2e-tests/src/test_requests.py` — which endpoints are called |
| 147 | +- `drift/instrumentation/<library>/e2e-tests/entrypoint.py` — test orchestration and setup |
131 | 148 |
|
132 | 149 | Understand what functionality is already tested and identify coverage gaps. |
133 | 150 |
|
| 151 | +- **If focus context provided**: What tests already exist for the focus area? What's missing? |
| 152 | + |
134 | 153 | ### 1.3 Analyze the Package Source Code |
135 | 154 |
|
136 | 155 | If you cloned the package source, read it to understand: |
137 | 156 |
|
138 | 157 | - The package's entry points and full API surface |
139 | 158 | - Functions that are currently patched vs functions that exist but aren't patched |
140 | 159 | - Alternative call patterns, overloads, and edge cases |
| 160 | +- **If focus context provided**: Deep-dive into the focus area's API surface and usage patterns |
141 | 161 |
|
142 | 162 | --- |
143 | 163 |
|
144 | 164 | ## Phase 2: Identify Potential Gaps |
145 | 165 |
|
| 166 | +**If focus context was provided**, prioritize bugs related to that area. You may still note other potential issues, but test the focus area first. |
| 167 | + |
146 | 168 | Reason about potential issues in the instrumentation. Consider: |
147 | 169 |
|
148 | 170 | - **Untested parameters**: Parameter combinations not covered by existing tests |
@@ -405,10 +427,7 @@ Commit the changes: |
405 | 427 |
|
406 | 428 | ```bash |
407 | 429 | git add drift/instrumentation/$ARGUMENTS/e2e-tests/ |
408 | | -git commit -m "bug-hunt($ARGUMENTS): add e2e tests exposing instrumentation bugs |
409 | | -
|
410 | | -Found N confirmed bugs in $ARGUMENTS instrumentation. |
411 | | -See BUG_TRACKING.md for details" |
| 430 | +git commit -m "bug-hunt($ARGUMENTS): add e2e tests exposing instrumentation bugs" |
412 | 431 | ``` |
413 | 432 |
|
414 | 433 | Push the branch (skip if in Claude Code Web where the session handles this): |
|
0 commit comments