backend/security/build.gradle (1)

99-100: Consider centralizing the junit-bom version to avoid drift.

You’re pinning 5.11.4 in multiple modules. To reduce duplication, define a shared junitVersion (e.g., in gradle.properties or the version catalog) and reference it everywhere.

backend/ktlint/build.gradle (1)

51-56: junit-bom import looks good; verify interaction with spring-boot-starter-test.

Overriding JUnit via junit-bom is fine even with spring-boot-starter-test present. Just ensure your chosen JUnit 5.11.4 works cleanly with Boot 3.4.8’s starter-test stack.

If you want to reduce duplication, consider moving the JUnit version to a single source (gradle.properties or version catalog) and referencing it here.

backend/app/src/main/kotlin/io/tolgee/configuration/openApi/OpenApiGroupBuilder.kt (5)

16-16: IdentityHashMap for OperationHandlers — verify identity stability across Springdoc phases

Switching to IdentityHashMap<Operation, HandlerMethod> is a clean way to avoid operationId collisions, but it assumes the same Operation instances flow through both OperationCustomizer (where the map is populated) and OpenApiCustomizer (where it’s read). If Springdoc clones/rebuilds Operation objects between phases, lookups will fail and later code will throw.

• Action: Verify at runtime that no “Operation handler not found …” is thrown and that handler lookups succeed across the whole OpenAPI generation.
• Optional: If you want extra safety, consider failing gracefully with a warning (and skipping the operation) rather than hard-throwing, or augment the error context as suggested below.

I can provide an integration test to assert handler mappings are resolvable across phases. Want me to draft it?

---

103-106: Method/class-level annotation lookup: consider supporting composed/meta-annotations

This works, but Spring’s AnnotationUtils.findAnnotation will also resolve composed/meta-annotations and bridge methods more robustly.

Apply this diff:

-    val annotation =
-      handlerMethod.getMethodAnnotation(annotationClass)
-        ?: handlerMethod.method.declaringClass.getAnnotation(annotationClass)
+    val annotation =
+      org.springframework.core.annotation.AnnotationUtils.findAnnotation(handlerMethod.method, annotationClass)
+        ?: org.springframework.core.annotation.AnnotationUtils.findAnnotation(handlerMethod.method.declaringClass, annotationClass)

---

160-160: Populating the identity map in OperationCustomizer — consider thread-safety (minor)

If Springdoc were to invoke OperationCustomizer concurrently, IdentityHashMap isn’t thread-safe. It’s likely single-threaded today, but a minimal hardening would be to wrap it with Collections.synchronizedMap.

For example (outside diffable range):

val operationHandlers: MutableMap<Operation, HandlerMethod> =
  java.util.Collections.synchronizedMap(java.util.IdentityHashMap())

---

179-181: Improve exception context when handler mapping is missing

Great that the message includes operationId. Adding path and HTTP method will make this much easier to debug.

Apply this diff:

-              operationHandlers[operation]
-                ?: throw RuntimeException("Operation handler not found for ${operation.operationId}"),
+              operationHandlers[operation]
+                ?: throw RuntimeException(
+                  "Operation handler not found. " +
+                  "operationId='${operation.operationId}', " +
+                  "path='${pathEntry.key}', " +
+                  "httpMethod='${oldPathItem.getHttpMethod(operation)}'"
+                ),

---

221-221: Optional: add debug logging when handler mapping is absent while building handlerPaths

This branch quietly skips when a handler isn’t found. A low-level debug log here would help catch identity mismatches early without failing the build.

backend/app/src/main/kotlin/io/tolgee/configuration/openApi/OpenApiConfiguration.kt (1)

119-124: Use shared helpers/constant for projectId detection; avoid hard-coded "{projectId}"

Good switch to identity-based lookup. For consistency and to prevent drift, prefer the existing helpers/constant over literal "{projectId}".

Apply this diff:

-        val pathContainsProjectId = path.contains("{$PROJECT_ID_PARAMETER}")
+        val pathContainsProjectId = containsProjectIdParam(path)
@@
-          ]?.any { it.contains("{projectId}") }
+          ]?.any { containsProjectIdParam(it) }

Also, same identity stability caveat as in OpenApiGroupBuilder applies here since this now keys by Operation. Please verify no runtime misses.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: cyyynthia
PR: tolgee/tolgee-platform#3126
File: backend/testing/build.gradle:78-78
Timestamp: 2025-06-11T16:17:35.696Z
Learning: The Gradle module `backend/testing` serves as an internal test pseudo-library; therefore, test-scope dependencies such as `org.springframework.boot:spring-boot-starter-test` are intentionally declared with `implementation`, as the module is only consumed on the test classpath and is not part of production artifacts.