Communication: Fix an issue when creating post in a private channel
#9896
Conversation
PaRangger
added
server
PaRangger
temporarily deployed
to
artemis-test2.artemis.cit.tum.de
GitHub Actions
Inactive
PaRangger
temporarily deployed
to
artemis-test6.artemis.cit.tum.de
GitHub Actions
Inactive
WalkthroughThe Changes
Possibly related PRs
Suggested labels
Suggested reviewers
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. 🔧 pmd (7.7.0)src/main/java/de/tum/cit/aet/artemis/communication/service/conversation/ConversationDTOService.javaThe following rules are missing or misspelled in your ruleset file category/vm/bestpractices.xml: BooleanInstantiation, DontImportJavaLang, DuplicateImports, EmptyFinallyBlock, EmptyIfStmt, EmptyInitializer, EmptyStatementBlock, EmptyStatementNotInLoop, EmptySwitchStatements, EmptySynchronizedBlock, EmptyTryBlock, EmptyWhileStmt, ExcessiveClassLength, ExcessiveMethodLength, ImportFromSamePackage, MissingBreakInSwitch, SimplifyBooleanAssertion. Please check your ruleset configuration. 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? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
src/main/java/de/tum/cit/aet/artemis/communication/service/conversation/ConversationDTOService.java (1)
262-269: Consider adding logging and metrics for better observabilityThe error handling logic correctly addresses the LazyInitializationException by falling back to repository query. However, for better monitoring and debugging:
- Consider logging the exception at DEBUG level
- Consider adding metrics to track fallback frequency
try { participantsInitialized = Persistence.getPersistenceUtil().isLoaded(conversation, "conversationParticipants") && conversation.getConversationParticipants() != null && !conversation.getConversationParticipants().isEmpty(); } catch (LazyInitializationException e) { + log.debug("Persistence context closed while checking conversation participants. Falling back to repository query.", e); + metricsRegistry.counter("conversation.participants.lazy_init_fallback").increment(); // In case the conversation's persistence context was closed already, we need to re-fetch to avoid errors down the line participantsInitialized = false; }
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
src/main/java/de/tum/cit/aet/artemis/communication/service/conversation/ConversationDTOService.java(2 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
src/main/java/de/tum/cit/aet/artemis/communication/service/conversation/ConversationDTOService.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
🔇 Additional comments (2)
src/main/java/de/tum/cit/aet/artemis/communication/service/conversation/ConversationDTOService.java (2)
12-12: LGTM: Required import for exception handling
The addition of LazyInitializationException import is necessary for the new error handling logic.
261-261: LGTM: Explicit type declaration improves clarity
Changed from var to boolean for better code readability and type safety.
| boolean participantsInitialized; | ||
| try { | ||
| participantsInitialized = Persistence.getPersistenceUtil().isLoaded(conversation, "conversationParticipants") && conversation.getConversationParticipants() != null | ||
| && !conversation.getConversationParticipants().isEmpty(); | ||
| } | ||
| catch (LazyInitializationException e) { | ||
| // In case the conversation's persistence context was closed already, we need to re-fetch to avoid errors down the line | ||
| participantsInitialized = false; | ||
| } |
There was a problem hiding this comment.
After some digging I get why this is necessary, but I still find it a bit weird to need to have try/catch if before there is an explicit check to prevent exactly that exception.
Under which circumstances does this trigger? Maybe it might make sense to fix the issue there?
There was a problem hiding this comment.
I agree, both, the old and the new code do not look very good!
There was a problem hiding this comment.
We use Hibernate.isInitialized(...) in some places. Would that help to improve the code?
Hibernate.isInitialized(conversation.getConversationParticipants())
krusche
changed the title
Communication: Fix exception being thrown when creating post in a private channelCommunication: Fix an issue when creating post in a private channel
|
There hasn't been any activity on this pull request recently. Therefore, this pull request has been automatically marked as stale and will be closed if no further activity occurs within seven days. Thank you for your contributions. |
…versation-participants
Checklist
General
Server
Motivation and Context
Currently, there is a rare exception being thrown when creating the first post in a one to one chat that looks like this:
This happens due to the conversations persistence context being closed under certain circumstances. This causes a
LazyInitializationExceptionbeing thrown when trying to loadconversation.getConversationParticipants(). More information about this issue can be found here.Description
I surrounded the code with a try-catch-block that handles the exception being thrown. In this rare case the repository then re-queries the database to retrieve the conversation participant list.
Steps for Testing
Prerequisites:
Testserver States
Note
These badges show the state of the test servers.
Green = Currently available, Red = Currently locked
Click on the badges to get to the test servers.
Review Progress
Performance Review
Code Review
Manual Tests
Test Coverage
TBD
Summary by CodeRabbit
Bug Fixes
Refactor