Avro schemas refactoring

[sleepkqq]

PR Type

Enhancement

---

Description

• Update transaction ID field naming from transactionId to txId

• Bump solo-leveling-lib dependency to version 1.2.1

• Align logging statements with new field name across consumers

---

Diagram Walkthrough

flowchart LR
  A["solo-leveling-lib 1.0.9"] -- "upgrade to 1.2.1" --> B["solo-leveling-lib 1.2.1"]
  C["transactionId field"] -- "rename to" --> D["txId field"]
  D -- "reflected in" --> E["Logging statements"]

Loading

File Walkthrough

	Relevant files
Enhancement	ReceiveNotificationProducer.kt Update transaction ID field in producer logging                    solo-leveling-notification-service/src/main/kotlin/com/sleepkqq/sololeveling/notification/kafka/ReceiveNotificationProducer.kt Updated log message to use txId instead of transactionId Reflects schema change from upgraded solo-leveling-lib dependency +1/-1      SendNotificationConsumer.kt Update transaction ID field in consumer logging                    solo-leveling-notification-service/src/main/kotlin/com/sleepkqq/sololeveling/notification/kafka/SendNotificationConsumer.kt Updated log message to use txId instead of transactionId Aligns with Avro schema changes in new library version +1/-1
Dependencies	pom.xml Upgrade solo-leveling-lib dependency version                          pom.xml Bumped solo-leveling-lib version from 1.0.9 to 1.2.1 Enables access to updated Avro schemas with new field naming +1/-1

---

[qodo-code-review]

PR Compliance Guide 🔍

(Compliance updated until commit f317ee4)

Below is a summary of compliance checks for this PR:

Security Compliance
⚪	Sensitive information exposure Description: Logging the transaction identifier event.txId may expose sensitive correlation data to logs, which could be accessible in shared log systems and aid attackers in tracing or replaying workflows. ReceiveNotificationProducer.kt [26-29] Referred Code log.info("<< Notification sent to {} | txId={}", topic, event.txId) } else { log.error("Failed to send notification to {} | txId={}", topic, event.txId, e) }
	Sensitive information exposure Description: Logging event.txId on consumption can leak sensitive correlation identifiers to logs, potentially aiding correlation across services if logs are compromised. SendNotificationConsumer.kt [37-37] Referred Code log.info("<< Start sending notification | txId={}", event.txId) val receiveNotificationEvent = avroMapper.map(event)
	Insecure JVM flags enabled Description: Running the application with JVM options --enable-native-access=ALL-UNNAMED and --add-opens java.base/java.lang=ALL-UNNAMED weakens the Java module boundaries system-wide, increasing the attack surface for exploitation via reflection or native access by third-party libraries. Dockerfile [33-37] Referred Code EXPOSE 8080 CMD ["java", \ "--enable-native-access=ALL-UNNAMED", \ "--add-opens", "java.base/java.lang=ALL-UNNAMED", \ "-Dspring.profiles.active=prod", \
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
⚪	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Async send errors: The Kafka send uses whenComplete to log failures but does not surface or handle errors beyond logging, making it unclear if retries or compensations occur for failed sends. Referred Code .whenComplete { _, e -> if (e == null) { log.info("<< Notification sent to {} | txId={}", topic, event.txId) } else { log.error("Failed to send notification to {} | txId={}", topic, event.txId, e) } } Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Listener group id: The Kafka listener’s groupId uses a property placeholder that appears malformed ($${}"${spring.kafka.avro.group-id}"), which may cause it to fall back to defaults and affect consumer isolation and security. Referred Code topics = [KafkaTaskTopics.SEND_NOTIFICATION_TOPIC], groupId = $$"${spring.kafka.avro.group-id}" ) fun listen(event: SendNotificationEvent) { consumeWithIdempotency(event) } Learn more about managing compliance generic rules or creating your own custom rules

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

---

Previous compliance checks

Compliance check up to commit 1efc72d

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
⚪	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Audit logging scope: The new logs record start of processing and send completion with txId, but it is unclear if failures, outcomes, or user context are logged, which may be required for comprehensive audit trails. Referred Code log.info("<< Start sending notification | txId={}", event.txId) val receiveNotificationEvent = avroMapper.map(event) receiveNotificationProducer.send(event.priority, receiveNotificationEvent) Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Missing error handling: The added flow logs success but does not show handling for send failures or mapping/listener edge cases, which may lead to silent failures depending on surrounding configuration. Referred Code fun send(priority: NotificationPriority, event: ReceiveNotificationEvent) = routingStrategy.getTopics(priority) .forEach { sendToTopic(it, event) } private fun sendToTopic(topic: String, event: ReceiveNotificationEvent) { kafkaTemplate.send(topic, event) log.info(">> Notification sent to {} | txId={}", topic, event.txId) } Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: External input handling: The consumer processes external Kafka events without visible validation or authorization checks in the new code section, which may require verification depending on upstream guarantees. Referred Code @KafkaListener( topics = [KafkaTaskTopics.SEND_NOTIFICATION_TOPIC], groupId = KafkaGroupIds.NOTIFICATION_GROUP_ID ) fun listen(event: SendNotificationEvent, ack: Acknowledgment) { log.info("<< Start sending notification | txId={}", event.txId) val receiveNotificationEvent = avroMapper.map(event) receiveNotificationProducer.send(event.priority, receiveNotificationEvent) Learn more about managing compliance generic rules or creating your own custom rules

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	✅ Handle asynchronous Kafka send result Suggestion Impact: The commit updated sendToTopic to use whenComplete on kafkaTemplate.send and added success and error logging, matching the suggested error handling. code diff: + kafkaTemplate.send(topic, event).whenComplete { _, ex -> + if (ex == null) { + log.info(">> Notification sent to {} | txId={}", topic, event.txId) + } else { + log.error("<< Failed to send notification to {} | txId={}", topic, event.txId, ex) + } + } Handle the CompletableFuture returned by kafkaTemplate.send to properly log success or failure of the asynchronous operation, preventing potential silent message loss. solo-leveling-notification-service/src/main/kotlin/com/sleepkqq/sololeveling/notification/kafka/ReceiveNotificationProducer.kt [22-25] private fun sendToTopic(topic: String, event: ReceiveNotificationEvent) { - kafkaTemplate.send(topic, event) - log.info(">> Notification sent to {} | txId={}", topic, event.txId) + kafkaTemplate.send(topic, event).whenComplete { _, ex -> + if (ex == null) { + log.info(">> Notification sent to {} | txId={}", topic, event.txId) + } else { + log.error("<< Failed to send notification to {} | txId={}", topic, event.txId, ex) + } + } } [Suggestion processed] Suggestion importance[1-10]: 8 __ Why: The suggestion correctly identifies unhandled asynchronous operation results, which could lead to silent message loss. Implementing this change significantly improves the application's robustness and reliability by adding proper error handling and logging for Kafka send operations.	Medium
Update