-
Notifications
You must be signed in to change notification settings - Fork 4
feat(speakers): display unique activities count on speakers/submitter… #921
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -20,7 +20,8 @@ import { | |
| SELECT_ALL_SUMMIT_SUBMITTERS, | ||
| UNSELECT_ALL_SUMMIT_SUBMITTERS, | ||
| SEND_SUBMITTERS_EMAILS, | ||
| SET_SUBMITTERS_CURRENT_FLOW_EVENT | ||
| SET_SUBMITTERS_CURRENT_FLOW_EVENT, | ||
| RECEIVE_SUBMITTERS_ACTIVITIES_COUNT | ||
| } from "../../actions/submitter-actions"; | ||
|
|
||
| import { | ||
|
|
@@ -38,6 +39,7 @@ const DEFAULT_STATE = { | |
| lastPage: 1, | ||
| perPage: 10, | ||
| totalItems: 0, | ||
| totalActivities: 0, | ||
| selectedCount: 0, | ||
| selectedItems: [], | ||
| excludedItems: [], | ||
|
|
@@ -193,6 +195,9 @@ const summitSubmittersListReducer = (state = DEFAULT_STATE, action) => { | |
| case SET_SUBMITTERS_CURRENT_FLOW_EVENT: { | ||
| return { ...state, currentFlowEvent: payload }; | ||
| } | ||
| case RECEIVE_SUBMITTERS_ACTIVITIES_COUNT: { | ||
| return { ...state, totalActivities: payload.response.count }; | ||
| } | ||
|
Comment on lines
+198
to
+200
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Guard against stale activity-count responses overwriting current filters. At Line 199, Consider attaching query context (e.g., 🤖 Prompt for AI Agents
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Every count request is fired at the exact same moment, with the exact same filter, as the main list request. Any rapid user interaction that could produce stale count responses would produce equally stale main list responses — and those have no guard. Adding a guard to just the new calls isn't solving a real problem that doesn't also exist on the main list, which the rest of the code base accepts without protection. Adding those guards everywhere they are needed would be more appropriately done as a separate project rather than in the context of this PR. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
(ᵔ.ᵔ) ✏️ Learnings added
🧠 Learnings used |
||
| default: | ||
| return state; | ||
| } | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prevent stale count responses from clobbering current speaker totals.
At Line 211, the reducer accepts whichever count response arrives last. Under rapid filter/search changes, stale responses can overwrite the active query’s
totalActivities.Please gate this update with request context (request id/filter hash/current summit) so only the latest relevant response updates state.
🤖 Prompt for AI Agents
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Every count request is fired at the exact same moment, with the exact same filter, as the main list request. Any rapid user interaction that could produce stale count responses would produce equally stale main list responses — and those have no guard. Adding a guard to just the new calls isn't solving a real problem that doesn't also exist on the main list, which the rest of the code base accepts without protection. Adding those guards everywhere they are needed would be more appropriately done as a separate project rather than in the context of this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mulldug, that's a fair and well-reasoned point. Since the count request is fired simultaneously with the main list request using the same filter, any stale-response race condition would affectRECEIVE_SPEAKERS_BY_SUMMITequally — and the existing reducer has no guard there either. Applying the guard selectively only to the new count action would indeed be inconsistent without broader refactoring. I agree this is better addressed as a dedicated follow-up across the codebase rather than piecemeal here.✏️ Learnings added
🧠 Learnings used