Skip to content
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

fix(j-s): Handle and log updated accused postponed appeal date #16555

Merged
merged 4 commits into from
Oct 25, 2024

Conversation

unakb
Copy link
Member

@unakb unakb commented Oct 24, 2024

https://app.asana.com/0/home/1203322535524092/1203701116749449

What

Handle and log cases where accused postponed appeal date is filled out before appeal is sent

Why

For better handling of appeals

Checklist:

  • I have performed a self-review of my own code
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • Formatting passes locally with my changes
  • I have rebased against main before asking for a review

Summary by CodeRabbit

  • New Features

    • Added a new test case to validate appeal information when a case has not been appealed.
    • Introduced logging for updates related to appeal dates, enhancing traceability.
  • Bug Fixes

    • Improved error handling in the update process, ensuring correct logging and exception management based on affected rows.

@unakb unakb requested a review from a team as a code owner October 24, 2024 15:20
Copy link
Contributor

coderabbitai bot commented Oct 24, 2024

Walkthrough

The changes involve enhancements to the appeal information handling within the judicial system's case management module. A new test case has been added to verify the behavior of the getAppealInfo function when a case has not been appealed. Modifications to the getAppealInfo function include updated logic for determining appeal status and deadlines. Additionally, logging functionality is introduced in the update methods of both CaseService and LimitedAccessCaseService classes to capture relevant appeal-related information during updates.

Changes

File Change Summary
apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.spec.ts Added a new test case in getAppealInfo to check that appealedDate is not returned if the case has not been appealed.
apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.ts Modified getAppealInfo to update logic for appeal information and deadlines; removed previous assignments for appeal-related properties.
apps/judicial-system/backend/src/app/modules/case/case.service.ts Introduced logging in the update method to capture appeal state and accusedPostponedAppealDate when present.
apps/judicial-system/backend/src/app/modules/case/limitedAccessCase.service.ts Added logging in the update method for accusedPostponedAppealDate and refined error handling logic.

Possibly related PRs

Suggested reviewers

  • oddsson

📜 Recent review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between f4020cd and d80cfae.

📒 Files selected for processing (4)
  • apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.spec.ts (1 hunks)
  • apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.ts (2 hunks)
  • apps/judicial-system/backend/src/app/modules/case/case.service.ts (1 hunks)
  • apps/judicial-system/backend/src/app/modules/case/limitedAccessCase.service.ts (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
  • apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.spec.ts
  • apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.ts
  • apps/judicial-system/backend/src/app/modules/case/case.service.ts
  • apps/judicial-system/backend/src/app/modules/case/limitedAccessCase.service.ts

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

🧹 Outside diff range and nitpick comments (5)
apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.ts (1)

129-134: Add type safety and documentation to appeal date transformation.

While the logic is correct, the code could benefit from improved type safety and documentation.

Consider these improvements:

+    // Only preserve postponed appeal dates if an appeal has been made
+    // to prevent showing stale dates for non-appealed cases
     accusedPostponedAppealDate: appealInfo.hasBeenAppealed
-      ? theCase.accusedPostponedAppealDate
+      ? theCase.accusedPostponedAppealDate ?? null
       : undefined,
     prosecutorPostponedAppealDate: appealInfo.hasBeenAppealed
-      ? theCase.prosecutorPostponedAppealDate
+      ? theCase.prosecutorPostponedAppealDate ?? null
       : undefined,
apps/judicial-system/backend/src/app/modules/case/limitedAccessCase.service.ts (1)

Line range hint 333-342: Improve error handling consistency

While the error handling covers the edge cases, it could be more consistent and actionable:

  1. The error for multiple rows affected should be treated as seriously as zero rows
  2. Error messages could provide more context for debugging

Consider this improved implementation:

 const [numberOfAffectedRows] = await this.caseModel.update(
   { ...update },
   { where: { id: theCase.id } },
 )

-if (numberOfAffectedRows > 1) {
-  // Tolerate failure, but log error
-  this.logger.error(
-    `Unexpected number of rows (${numberOfAffectedRows}) affected when updating case ${theCase.id}`,
-  )
-} else if (numberOfAffectedRows < 1) {
+if (numberOfAffectedRows !== 1) {
+  const errorMessage = numberOfAffectedRows > 1
+    ? `Multiple rows (${numberOfAffectedRows}) affected when updating case`
+    : 'No rows affected during update'
+
   throw new InternalServerErrorException(
-    `Could not update case ${theCase.id}`,
+    `Update failed for case ${theCase.id}: ${errorMessage}`,
+    {
+      cause: {
+        caseId: theCase.id,
+        affectedRows: numberOfAffectedRows,
+        update,
+      },
+    }
   )
 }
apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.spec.ts (2)

543-566: Suggest improving test name for clarity.

The current test name "should return not return appealedDate if case has not been appealed" has a grammatical error and could be more descriptive. Consider renaming to better reflect the edge case being tested.

-  it('should return not return appealedDate if case has not been appealed', () => {
+  it('should not return appealedDate when appeal is postponed but not yet submitted', () => {

543-566: Add documentation for edge case context.

Consider adding a comment to explain the significance of this test case, as it verifies an important edge case where postponed appeal dates are set but the appeal hasn't been formally submitted.

+    // This test verifies that even when postponed appeal dates are set,
+    // the appealedDate should not be returned until the appeal is formally
+    // submitted (appealState is set)
     const rulingDate = new Date().toISOString()
apps/judicial-system/backend/src/app/modules/case/case.service.ts (1)

1672-1687: LGTM! Consider adding type safety for the logged object.

The logging implementation follows good practices with structured JSON format and captures relevant appeal information without exposing sensitive data.

Consider defining an interface for the logged object to ensure type safety:

interface AppealDateUpdateInfo {
  appealState: CaseAppealState;
  accusedAppealDecision: CaseAppealDecision;
  accusedPostponedAppealDate: Date | null;
  prosecutorAppealDecision: CaseAppealDecision;
  prosecutorPostponedAppealDate: Date | null;
  update: Partial<Pick<UpdateCase, 'accusedPostponedAppealDate'>>;
}

Then use it in the logging:

-      const relevantInfo = {
+      const relevantInfo: AppealDateUpdateInfo = {
         appealState: theCase.appealState,
         accusedAppealDecision: theCase.accusedAppealDecision,
         accusedPostponedAppealDate: theCase.accusedPostponedAppealDate,
         prosecutorAppealDecision: theCase.prosecutorAppealDecision,
         prosecutorPostponedAppealDate: theCase.prosecutorPostponedAppealDate,
         update: update,
       }
📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 1a30e6b and f4020cd.

📒 Files selected for processing (4)
  • apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.spec.ts (1 hunks)
  • apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.ts (2 hunks)
  • apps/judicial-system/backend/src/app/modules/case/case.service.ts (1 hunks)
  • apps/judicial-system/backend/src/app/modules/case/limitedAccessCase.service.ts (1 hunks)
🧰 Additional context used
📓 Path-based instructions (4)
apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.spec.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/backend/src/app/modules/case/case.service.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/backend/src/app/modules/case/limitedAccessCase.service.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
🔇 Additional comments (2)
apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.ts (1)

65-78: Verify logging implementation for appeal date changes.

The PR objectives mention logging of appeal date changes, but no logging is implemented in this transformer. Ensure that logging is implemented in the appropriate service layer.

apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.spec.ts (1)

543-566: LGTM! Test implementation is thorough and well-structured.

The test case:

  • Properly validates the edge case of postponed but not submitted appeals
  • Has comprehensive assertions covering all relevant appeal info properties
  • Follows the established testing patterns in the codebase

Copy link

codecov bot commented Oct 24, 2024

Codecov Report

Attention: Patch coverage is 90.90909% with 2 lines in your changes missing coverage. Please review.

Project coverage is 36.77%. Comparing base (ab72373) to head (d80cfae).
Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
...ystem/backend/src/app/modules/case/case.service.ts 33.33% 2 Missing ⚠️
Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main   #16555      +/-   ##
==========================================
- Coverage   36.80%   36.77%   -0.03%     
==========================================
  Files        6854     6852       -2     
  Lines      142215   142166      -49     
  Branches    40549    40544       -5     
==========================================
- Hits        52336    52286      -50     
- Misses      89879    89880       +1     
Flag Coverage Δ
judicial-system-api 19.33% <100.00%> (+0.12%) ⬆️
judicial-system-backend 55.31% <66.66%> (+<0.01%) ⬆️
web 1.80% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
.../app/modules/case/interceptors/case.transformer.ts 100.00% <100.00%> (ø)
.../src/app/modules/case/limitedAccessCase.service.ts 74.16% <100.00%> (+0.66%) ⬆️
...ystem/backend/src/app/modules/case/case.service.ts 90.40% <33.33%> (-0.32%) ⬇️

... and 14 files with indirect coverage changes


Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ab72373...d80cfae. Read the comment docs.

@datadog-island-is
Copy link

Datadog Report

All test runs 0607f24 🔗

2 Total Test Services: 0 Failed, 2 Passed
⬆️ Test Sessions change in coverage: 1 increased (+0.03%), 1 no change

Test Services
Service Name Failed Known Flaky New Flaky Passed Skipped Total Time Code Coverage Change Test Service View
judicial-system-api 0 0 0 58 0 7.09s 1 increased (+0.03%) Link
judicial-system-backend 0 0 0 21260 0 20m 26.72s 1 no change Link

@unakb unakb added the automerge Merge this PR as soon as all checks pass label Oct 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
automerge Merge this PR as soon as all checks pass
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants