Commit 551e7f7
committed
fix(github-graphql): prevent panic in graphql rate limit polling goroutine
Replace panic in GraphqlAsyncClient rate-limit polling goroutine with graceful error handling.
Previously, any error while fetching rate limit (e.g., transient network issues or 401 responses) would trigger a panic inside a background goroutine, crashing the entire DevLake process.
Now, errors are logged and the client retries in the next cycle while retaining the last known rate limit.
Design decisions:
- Avoid panic in background goroutines: rate-limit polling is non-critical and should not bring down the entire pipeline.
- Use last known rateRemaining on runtime failures instead of resetting or blocking, ensuring continued progress with eventual consistency.
- Retry via existing polling mechanism instead of immediate retry to prevent tight retry loops and unnecessary API pressure.
- Introduce a default fallback (5000) only for initial rate-limit fetch failures, since no prior state exists at startup.
- Separate handling of initial vs runtime failures:
- Initial failure → fallback to default (5000)
- Runtime failure → retain previous value
Fixes #8788 (bug 1)1 parent b68c102 commit 551e7f7
1 file changed
Lines changed: 9 additions & 3 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
47 | 47 | | |
48 | 48 | | |
49 | 49 | | |
| 50 | + | |
| 51 | + | |
50 | 52 | | |
51 | 53 | | |
52 | 54 | | |
| |||
68 | 70 | | |
69 | 71 | | |
70 | 72 | | |
71 | | - | |
| 73 | + | |
| 74 | + | |
| 75 | + | |
| 76 | + | |
72 | 77 | | |
73 | | - | |
74 | 78 | | |
75 | 79 | | |
76 | 80 | | |
| |||
126 | 130 | | |
127 | 131 | | |
128 | 132 | | |
129 | | - | |
| 133 | + | |
| 134 | + | |
| 135 | + | |
130 | 136 | | |
131 | 137 | | |
132 | 138 | | |
| |||
0 commit comments