Adding locking for multiple order creation

[sehjotsinghunthinkable]

📋 Description

JIRA ID: AMM-2528

• ✨ New feature (non-breaking change which adds functionality)

Summary by CodeRabbit

• Reliability
  • Diagnostic requests can wait up to 60 seconds for a response before timing out.
  • Creating and sending diagnostic orders for the same beneficiary and order type is now serialized to reduce overlapping operations.
  • If an order operation cannot acquire its turn within 30 seconds, it fails with an error; the operation lock is released when processing finishes or fails.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 8714c8d7-da4d-488a-bb84-ca1151acde9a

📥 Commits

Reviewing files that changed from the base of the PR and between 4398d78 and bee2f14.

📒 Files selected for processing (2)

• src/main/java/com/iemr/flw/integration/provider/emrlite/EmrLiteRestTemplateConfig.java
• src/main/java/com/iemr/flw/service/impl/DiagnosticOrderServiceImpl.java

Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.

📝 Walkthrough

The EMR Lite diagnostic client now uses explicit connection and read timeouts. Diagnostic order creation and push operations now acquire a lock keyed by beneficiary ID and order type.

Changes: EMR Lite request timeouts

Layer / File(s)	Summary
Configure EMR Lite request timeouts src/main/java/com/iemr/flw/integration/provider/emrlite/EmrLiteRestTemplateConfig.java	The authenticated EMR Lite RestTemplate now sets a 20-second connect timeout and a 60-second read timeout.

Diagnostic order locking

Layer / File(s)	Summary
Lock diagnostic order operations src/main/java/com/iemr/flw/service/impl/DiagnosticOrderServiceImpl.java	createAndPushOrder now runs through a lock keyed by beneficiary ID and order type. It rejects null keys, waits up to 30 seconds to acquire the lock, and releases the lock after the operation returns or fails.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~15 minutes

Change: Bug fix

Suggested reviewers: vishwab1

Merge Risk: ⚪ Minimal · up to bee2f

The same-key contention path returns a bounded “retry shortly” response. This review found no supported merge-blocking failure.

Pre-merge checks · 4 · 1

Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage		Docstring coverage is 25.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 4 functions across 2 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

Passed checks (4 passed)

Check name	Status	Explanation
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		The title clearly identifies the main change: adding locking to prevent concurrent order creation. It is concise and related to the changeset.
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

• Fix all pre-merge checks with AI

✨ Finishing Touches 💡 1

🛠️ Fix failing CI checks 💡

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[sehjotsinghunthinkable]

@coderabbitai review

[coderabbitai]

✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.