Repository navigation
Conversation
![aikido-pr-checks[bot]](https://avatars.githubusercontent.com/in/898896?s=60&v=4){kind=small}
| // make api calls on start, slow responses should not delay the tasks above | ||
| Optional<APIResponse> res = api.report(Started.get()); | ||
| res.ifPresent(ServiceConfigStore::updateFromAPIResponse); | ||
| // Fetch blocked lists using separate API call |
There was a problem hiding this comment.
The comment that blocked lists use a separate API call restates api.fetchBlockedLists() without adding context.
| // Fetch blocked lists using separate API call |
Details
✨ AI Reasoning
The comment repeats what the adjacent api.fetchBlockedLists() call already shows and gives no reason for making it a separate call. The other added comment explains that slow responses should not delay scheduled tasks, so it provides rationale.
Reply on this comment to give feedback or ignore the issue.
More info
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
a92de90 to
6fb3e6d
Compare
| Optional<APIResponse> res = api.report(Started.get()); | ||
| res.ifPresent(ServiceConfigStore::updateFromAPIResponse); | ||
| // Fetch blocked lists using separate API call | ||
| Optional<ReportingApi.APIListsResponse> listsRes = api.fetchBlockedLists(); | ||
| listsRes.ifPresent(ServiceConfigStore::updateFromAPIListsResponse); |
There was a problem hiding this comment.
🟠 High - Concurrent startup refreshes can overwrite newer blocking rules
When the startup event or list request takes longer than the newly scheduled 30/60-second tasks, HeartbeatTask or RealtimeTask can fetch a newer configuration while the original startup responses are still in flight. The startup responses are then applied without version checks, and a late list response replaces the entire list set, so newly enabled IP/UA blocks or blocking mode can be reverted and matching requests or attacks can pass until a later refresh.
Show fix
Keep startup fetches serialized ahead of scheduled refreshes, or make configuration and list updates version-aware so an older response cannot replace a newer snapshot. Do not let the initial list response clear newer rules based solely on arrival order.
More info - Reply on this comment to give feedback or ignore the issue.
No description provided.