Release 3.7.1 to main#140
Open
snehar-nd wants to merge 38 commits into
Open
Conversation
fix: amm-2140 stillbirth and abortion report download issue
Upgrade version from 3.6.0 to 3.7.0
fix: amm-2140 baby death report download issue
amm-2140 misscarriage report fix
amm-2140 misscarriage report fix
…loocating on same date itself
Reassign calls from MO to ANM and display HRP in ANM worklist
changes made for disconnected call and call allocation
When a call is closed with a not-answered reason (Number busy, Switched off, No reply, etc.), the call was being unallocated from the agent due to isCallDisconnected being forced true. This fix restores the agent allocation so the record stays visible in the agent's worklist for retry. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Roshini's change unallocated ALL disconnected calls including busy ones. Fixed at root cause - unallocation now skipped when reason is a not-answered type (busy, switched off, no reply etc). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
fix: busy/not-answered calls stay in agent worklist after call closure
Adds composite DB indexes on t_mctsoutboundcalls, t_childvaliddata, and t_mothervalidrecord to fix the 504 Gateway Timeout on the Child+Self call allocation info endpoint. Existing single-column indexes on low- cardinality columns (phoneNumberType=2, ProviderServiceMapID=2) were being skipped by the MySQL optimizer, causing full scans of 4M+ rows. Run db_indexes_performance.sql directly on production DB — no deployment needed. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…ordsInfo The Child+Self call allocation info endpoint timed out (504) because getEligibleRecordsInfo fired 3 separate COUNT queries against t_mctsoutboundcalls (4M rows) sequentially — each doing a full table scan. Q3 (HR unallocated) returned 0 rows but still scanned all 4M rows. Fix: replace the 3 separate queries with a single native SQL query using SUM(CASE WHEN) conditional aggregation. One table scan now returns all three counts (LR unallocated, HR unallocated, allocated) instead of three independent scans. Same fix applied to the Mother path. Combined with composite DB indexes in db_indexes_performance.sql, this reduces response time from 60s+ timeout to under 1s. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…y migration Indexes belong in the DB migration repo, not the application repo. See AMRIT-DB V83__ECD_outbound_calls_performance_indexes.sql. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…o fix 504 Converts getChildUnAllocatedCountLR, getChildUnAllocatedCountHR, and getTotalAllocatedCountChild to native queries with FORCE INDEX hint so MySQL uses the correct index instead of doing a full scan of 4M rows. Reverts consolidated SUM(CASE WHEN) approach — back to 3 separate queries, each now guided to idx_mcts_eligible_v2 via FORCE INDEX. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…k to 3 separate calls Removes unused getChildCountsLRHRAllocated and getMotherCountsLRHRAllocated from OutboundCallsRepo. Reverts mother count block in CallAllocationImpl to use the original 3 separate query methods. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Addresses reviewer comment: use OutboundCalls entity and mapped field names instead of raw table/column names with FORCE INDEX. Performance is handled by the restructured idx_mcts_eligible_v2 index (AMRIT-DB V84 migration). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…o fix 504 Reverts JPQL queries back to native SQL with FORCE INDEX hint on getChildUnAllocatedCountLR, getChildUnAllocatedCountHR, and getTotalAllocatedCountChild. FORCE INDEX is required to guarantee MySQL uses idx_mcts_eligible_v2 (restructured via AMRIT-DB V84 migration) instead of falling back to a full table scan on 4M+ rows. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…bleRecordsInfo Fix/504 composite indexes get eligible records info
Rebase 3.7.1 to main
Bump version from 3.7.0 to 3.7.1
📝 WalkthroughWalkthroughThe PR updates outbound-call allocation count queries, conditional call-closure resets, Excel upload size validation, and the Maven project version. ChangesAllocation and upload behavior
Release metadata
Estimated code review effort: 3 (Moderate) | ~25 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 Checkov (3.3.8)pom.xmlTraceback (most recent call last): 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. Comment |
vanitha1822
approved these changes
Jun 30, 2026
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@src/main/java/com/iemr/ecd/service/data_upload/RCHDataUploadServiceImpl.java`:
- Around line 85-88: Reinstate a maximum row-count validation in the workbook
processing flow of RCHDataUploadServiceImpl after opening the workbook and
before creating or retaining MotherRecord/ChildRecord entities. Enforce a
reasonable limit of 5,000–10,000 rows, reject oversized workbooks with an
ECDException, and preserve the existing file-size validation and saveAll
behavior for valid inputs.
- Around line 85-88: Move the size validation in the RCH data upload flow to the
Base64 input before Base64.decodeBase64 executes. Estimate the decoded byte
length from the encoded payload, account for padding as needed, and throw the
existing ECDException when the estimate exceeds MAX_FILE_SIZE_BYTES; retain the
post-decode check only if needed for exact validation.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: a7f6e420-4e5a-4884-8cc0-9749bddd5bfd
📒 Files selected for processing (5)
pom.xmlsrc/main/java/com/iemr/ecd/repo/call_conf_allocation/OutboundCallsRepo.javasrc/main/java/com/iemr/ecd/service/associate/CallClosureImpl.javasrc/main/java/com/iemr/ecd/service/call_conf_allocation/CallAllocationImpl.javasrc/main/java/com/iemr/ecd/service/data_upload/RCHDataUploadServiceImpl.java
Comment on lines
+85
to
+88
|
|
||
| if (excelDataBytes.length > MAX_FILE_SIZE_BYTES) | ||
| throw new ECDException("File size exceeds the maximum allowed limit of 5MB"); | ||
|
|
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
Reinstate a row count validation limit to prevent memory exhaustion.
Relying solely on a 5MB file-size limit introduces a severe memory exhaustion (OOM) vulnerability. Because .xlsx files are highly compressed ZIP archives, a 5MB file can easily contain hundreds of thousands of rows.
Processing and retaining this many MotherRecord or ChildRecord entities in memory to persist them in a single JPA saveAll batch will likely cause heap exhaustion or database transaction timeouts. Please reinstate a reasonable row count validation (e.g., 5,000 to 10,000 rows max) after opening the workbook to safeguard system stability.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/main/java/com/iemr/ecd/service/data_upload/RCHDataUploadServiceImpl.java`
around lines 85 - 88, Reinstate a maximum row-count validation in the workbook
processing flow of RCHDataUploadServiceImpl after opening the workbook and
before creating or retaining MotherRecord/ChildRecord entities. Enforce a
reasonable limit of 5,000–10,000 rows, reject oversized workbooks with an
ECDException, and preserve the existing file-size validation and saveAll
behavior for valid inputs.
🚀 Performance & Scalability | 🟡 Minor | ⚡ Quick win
Fast-fail on oversized Base64 payloads before decoding.
Validating the file size only after Base64.decodeBase64 executes allows exceptionally large payloads to allocate massive byte arrays in memory, leading to unnecessary CPU cycles and a potential OutOfMemoryError (OOM) before the size limit safeguard is even reached.
Check the estimated length of the Base64 string before decoding to safely fail fast.
⚡ Proposed optimization
String base64File = rchFileUploadDto.getFileContent();
+
+ // Fast-fail on absurdly large payloads to prevent OOM during decoding.
+ // A Base64 string's length is roughly 4/3 of the decoded byte array.
+ if (base64File.length() > MAX_FILE_SIZE_BYTES * 2) {
+ throw new ECDException("File size significantly exceeds the maximum allowed limit");
+ }
+
byte[] excelDataBytes = Base64.decodeBase64(base64File);
if (excelDataBytes.length > MAX_FILE_SIZE_BYTES)📝 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.
Suggested change
| if (excelDataBytes.length > MAX_FILE_SIZE_BYTES) | |
| throw new ECDException("File size exceeds the maximum allowed limit of 5MB"); | |
| String base64File = rchFileUploadDto.getFileContent(); | |
| // Fast-fail on absurdly large payloads to prevent OOM during decoding. | |
| // A Base64 string's length is roughly 4/3 of the decoded byte array. | |
| if (base64File.length() > MAX_FILE_SIZE_BYTES * 2) { | |
| throw new ECDException("File size significantly exceeds the maximum allowed limit"); | |
| } | |
| byte[] excelDataBytes = Base64.decodeBase64(base64File); | |
| if (excelDataBytes.length > MAX_FILE_SIZE_BYTES) | |
| throw new ECDException("File size exceeds the maximum allowed limit of 5MB"); |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/main/java/com/iemr/ecd/service/data_upload/RCHDataUploadServiceImpl.java`
around lines 85 - 88, Move the size validation in the RCH data upload flow to
the Base64 input before Base64.decodeBase64 executes. Estimate the decoded byte
length from the encoded payload, account for padding as needed, and throw the
existing ECDException when the estimate exceeds MAX_FILE_SIZE_BYTES; retain the
post-decode check only if needed for exact validation.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
📋 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
New Features
Bug Fixes
Release