Callallocation count mismatch#84
Conversation
WalkthroughThis update modifies JPQL queries in Changes
Sequence Diagram(s)sequenceDiagram
participant Caller
participant CallClosureImpl
participant OutboundCallsRepo
Caller->>CallClosureImpl: closeCall()
alt Call type is introductory and disconnected
CallClosureImpl--x OutboundCallsRepo: (No allocation status reset)
end
CallClosureImpl->>OutboundCallsRepo: Update call status as needed
sequenceDiagram
participant Service
participant CallAllocationImpl
participant OutboundCallsRepo
Service->>CallAllocationImpl: allocateMotherRecordsAssociates()
alt Preferred language is present
CallAllocationImpl->>OutboundCallsRepo: saveAll(outBoundCallList) (immediately after processing)
else
CallAllocationImpl->>OutboundCallsRepo: saveAll(outBoundCallList) (as before)
end
Possibly related PRs
Suggested reviewers
Poem
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
|
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
src/main/java/com/iemr/ecd/service/associate/CallClosureImpl.java (1)
162-162: Add documentation for commented code.The commented line suggests a deliberate change in how introductory calls are handled, but lacks explanation. This aligns with the repository changes that exclude introductory calls from allocation queries.
Consider adding a comment explaining why this logic was disabled:
if ("introductory".equalsIgnoreCase(callObj.getEcdCallType()) && Boolean.TRUE.equals(obj.getIsCallDisconnected()) && StringUtils.hasText(request.getPreferredLanguage())) { callObj.setCallStatus(Constants.OPEN); - //callObj.setAllocationStatus(Constants.UNALLOCATED); + // Note: Allocation status is no longer reset to UNALLOCATED for introductory calls + // as they are now excluded from allocation queries (see OutboundCallsRepo changes) + //callObj.setAllocationStatus(Constants.UNALLOCATED);src/main/java/com/iemr/ecd/repo/call_conf_allocation/OutboundCallsRepo.java (1)
124-125: High-risk child count query includes filtering.The query structure spans two lines but maintains the same filtering logic. Consider formatting consistency.
For better readability, consider formatting the query condition consistently:
- + " t.childId IS NOT NULL AND t.isHrni = true " + " AND t.phoneNumberType=:phoneNoType AND t.deleted = false AND t.displayEcdCallType != 'introductory'" - + " AND (t.isFurtherCallRequired = true OR t.isFurtherCallRequired IS NULL )") + + " t.childId IS NOT NULL AND t.isHrni = true AND t.phoneNumberType=:phoneNoType AND t.deleted = false AND t.displayEcdCallType != 'introductory' " + + " AND (t.isFurtherCallRequired = true OR t.isFurtherCallRequired IS NULL )")
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
src/main/java/com/iemr/ecd/repo/call_conf_allocation/OutboundCallsRepo.java(4 hunks)src/main/java/com/iemr/ecd/service/associate/CallClosureImpl.java(2 hunks)src/main/java/com/iemr/ecd/service/call_conf_allocation/CallAllocationImpl.java(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: Analyze (java)
🔇 Additional comments (9)
src/main/java/com/iemr/ecd/service/associate/CallClosureImpl.java (1)
206-206: Minor formatting improvement.The blank line improves code readability by separating logical sections.
src/main/java/com/iemr/ecd/repo/call_conf_allocation/OutboundCallsRepo.java (8)
75-76: Consistent filtering applied to ANM child records query.The same introductory call exclusion pattern is applied here, maintaining consistency with the mother records query.
86-86: MO mother records query excludes introductory calls.The filtering logic is consistently applied to Medical Officer queries as well.
92-92: MO child records query includes introductory call exclusion.Consistent with other role-based queries.
101-101: Count queries updated to exclude introductory calls.The count queries for unallocated mother records now exclude introductory calls, which should resolve count mismatches mentioned in the PR title.
109-109: Child count query consistently excludes introductory calls.Maintains consistency across mother and child count operations.
117-117: High-risk mother count query updated.The exclusion of introductory calls is applied to high-risk scenarios as well.
132-132: Allocated mother count includes further call requirement filter.The allocated count queries now include the
isFurtherCallRequiredfilter, ensuring consistent counting logic.
139-139: Allocated child count maintains consistency.The same filtering logic is applied to child allocated counts.
| } | ||
| } | ||
|
|
||
| outboundCallsRepo.saveAll(outBoundCallList); |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify transaction consistency with early save operation.
The save operation has been moved earlier to persist outbound calls immediately after processing the preferred language branch, rather than waiting until method completion. While this can improve data consistency, ensure this doesn't create issues with transaction rollback scenarios.
Please verify that this timing change doesn't affect transaction handling, especially if an exception occurs in the subsequent else branch (lines 151-191).
🏁 Script executed:
#!/bin/bash
# Description: Search for transaction annotations and error handling patterns in this method
# Check for transaction boundaries and exception handling
ast-grep --pattern $'@Transactional($$$)
$$$
public String allocateMotherRecordsAssociates($$$) {
$$$
}'
# Look for try-catch blocks that might affect transaction rollback
rg -A 10 -B 5 "catch.*Exception" src/main/java/com/iemr/ecd/service/call_conf_allocation/CallAllocationImpl.javaLength of output: 8977
Ensure transactional boundary covers early saveAll call.
The early outboundCallsRepo.saveAll(outBoundCallList); in allocateMotherRecordsAssociates executes outside any @Transactional scope and will commit immediately, making it impossible to roll back if a later exception occurs. Please adjust as follows:
• File: src/main/java/com/iemr/ecd/service/call_conf_allocation/CallAllocationImpl.java
– Locate the public method that invokes allocateMotherRecordsAssociates (around line 150).
– Add or move the Spring transaction annotation to wrap the entire flow, for example:
@Transactional(rollbackOn = Exception.class)
public String [yourPublicMethodName](RequestCallAllocationDTO dto) { … }• Alternatively, annotate allocateMotherRecordsAssociates itself (and make it public) with @Transactional(rollbackOn = Exception.class) so both the early and final saveAll occur within the same transaction.
This will ensure that if any subsequent error is thrown, all database changes—including the early save—are rolled back together.
🤖 Prompt for AI Agents
In
src/main/java/com/iemr/ecd/service/call_conf_allocation/CallAllocationImpl.java
at line 150, the early call to outboundCallsRepo.saveAll(outBoundCallList)
occurs outside a transactional boundary, risking partial commits if later
exceptions happen. To fix this, ensure the entire method flow including this
saveAll call is wrapped in a Spring transaction by adding
@Transactional(rollbackOn = Exception.class) either on the public method that
calls allocateMotherRecordsAssociates or directly on
allocateMotherRecordsAssociates itself (making it public if needed). This
guarantees all database operations are atomic and rollback together on errors.
| + " t.childId IS NULL AND t.motherId IS NOT NULL AND (t.isHighRisk = false OR t.isHighRisk IS NULL ) AND" | ||
| + " mv.preferredLanguage = :preferredLanguage AND t.displayEcdCallType != 'introductory' AND" | ||
| + " (t.isFurtherCallRequired = true OR t.isFurtherCallRequired IS NULL )") |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Systematic exclusion of introductory calls from ANM mother records query.
The query now excludes records where displayEcdCallType = 'introductory' and only includes calls requiring further action. This is a significant behavioral change that should be consistently applied across all related queries.
Verify that this filtering logic is consistently applied across all allocation queries to prevent count mismatches:
🏁 Script executed:
#!/bin/bash
# Description: Check consistency of introductory call exclusion across all queries
# Search for queries that might still include introductory calls
rg -n "displayEcdCallType" src/main/java/com/iemr/ecd/repo/call_conf_allocation/OutboundCallsRepo.java
# Look for any allocation queries that don't have the introductory exclusion
rg -A 3 -B 3 "allocationStatus.*=.*allocationStatus" src/main/java/com/iemr/ecd/repo/call_conf_allocation/OutboundCallsRepo.javaLength of output: 11155
🏁 Script executed:
#!/bin/bash
# Verify displayEcdCallType exclusion in allocated count queries
rg -n -C3 "getTotalAllocatedCountMother" src/main/java/com/iemr/ecd/repo/call_conf_allocation/OutboundCallsRepo.java
rg -n -C3 "getTotalAllocatedCountChild" src/main/java/com/iemr/ecd/repo/call_conf_allocation/OutboundCallsRepo.javaLength of output: 1597
Add displayEcdCallType != 'introductory' to allocated count queries
The JPQL methods for total allocated counts aren’t excluding introductory calls, which will lead to mismatches with the other queries:
• File: src/main/java/com/iemr/ecd/repo/call_conf_allocation/OutboundCallsRepo.java
– getTotalAllocatedCountMother (lines 130–134)
– getTotalAllocatedCountChild (lines 137–141)
Please update both queries to include the introductory‐call filter. For example:
@Query(value = " SELECT COUNT(1) FROM OutboundCalls AS t WHERE … "
- + " AND t.phoneNumberType=:phoneNoType AND (t.isFurtherCallRequired = true OR t.isFurtherCallRequired IS NULL )")
+ + " AND t.phoneNumberType=:phoneNoType"
+ + " AND t.displayEcdCallType != 'introductory'"
+ + " AND (t.isFurtherCallRequired = true OR t.isFurtherCallRequired IS NULL )")📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| + " t.childId IS NULL AND t.motherId IS NOT NULL AND (t.isHighRisk = false OR t.isHighRisk IS NULL ) AND" | |
| + " mv.preferredLanguage = :preferredLanguage AND t.displayEcdCallType != 'introductory' AND" | |
| + " (t.isFurtherCallRequired = true OR t.isFurtherCallRequired IS NULL )") | |
| // Apply this change in both getTotalAllocatedCountMother and getTotalAllocatedCountChild | |
| @Query(value = " SELECT COUNT(1) FROM OutboundCalls AS t WHERE … " | |
| + " AND t.phoneNumberType=:phoneNoType" | |
| + " AND t.displayEcdCallType != 'introductory'" | |
| + " AND (t.isFurtherCallRequired = true OR t.isFurtherCallRequired IS NULL )") |
🤖 Prompt for AI Agents
In src/main/java/com/iemr/ecd/repo/call_conf_allocation/OutboundCallsRepo.java
around lines 130 to 134 and 137 to 141, the JPQL queries in
getTotalAllocatedCountMother and getTotalAllocatedCountChild methods do not
exclude records where displayEcdCallType equals 'introductory'. To fix this, add
the condition "AND t.displayEcdCallType != 'introductory'" to both queries to
ensure consistency with other queries that exclude introductory calls and
prevent count mismatches.
📋 Description
JIRA ID:
Please provide a summary of the change and the motivation behind it. Include relevant context and details.
✅ Type of Change
ℹ️ Additional Information
Please describe how the changes were tested, and include any relevant screenshots, logs, or other information that provides additional context.
Summary by CodeRabbit