Coming from here
Background:
Multiple components (ReportActionsList, ReportScreen, scroll tracking hooks) independently call /ReadNewestAction API in response to report state changes, focus events, scroll position updates, and new messages. Each component uses useEffect hooks that monitor different aspects of user interaction with reports, operating without coordination between components.
Problem:
When users interact with expense reports, multiple components trigger simultaneous /ReadNewestAction API calls for the same report, which creates unnecessary server load and potential race conditions.
Solution:
Implement a request conflict resolver that examines the pending request queue before adding new /ReadNewestAction requests. The resolver compares lastReadTime parameters - if an existing request for the same reportID has an older timestamp, it's replaced with the new request; if it has a newer timestamp, the new request is discarded. This uses the existing RequestConflictUtils.resolveReadNewestActionConflicts function that returns replace, push, or noAction based on timestamp comparison, ensuring only the most recent read time reaches the server.
Issue Owner
Current Issue Owner: @johncschuster
Upwork Automation - Do Not Edit
- Upwork Job URL: https://www.upwork.com/jobs/~021932032042580415289
- Upwork Job ID: 1932032042580415289
- Last Price Increase: 2025-06-09
Coming from here
Background:
Multiple components (ReportActionsList, ReportScreen, scroll tracking hooks) independently call /ReadNewestAction API in response to report state changes, focus events, scroll position updates, and new messages. Each component uses useEffect hooks that monitor different aspects of user interaction with reports, operating without coordination between components.
Problem:
When users interact with expense reports, multiple components trigger simultaneous /ReadNewestAction API calls for the same report, which creates unnecessary server load and potential race conditions.
Solution:
Implement a request conflict resolver that examines the pending request queue before adding new /ReadNewestAction requests. The resolver compares lastReadTime parameters - if an existing request for the same reportID has an older timestamp, it's replaced with the new request; if it has a newer timestamp, the new request is discarded. This uses the existing RequestConflictUtils.resolveReadNewestActionConflicts function that returns replace, push, or noAction based on timestamp comparison, ensuring only the most recent read time reaches the server.
Issue Owner
Current Issue Owner: @johncschusterUpwork Automation - Do Not Edit