test(deepseekr1): agentic review — us.deepseek.r1-v1

[wezell]

Clean single-model e2e of the agentic reviewer (dotCMS/ai-workflows#55 @v3.3.0-beta.10).

Model: us.deepseek.r1-v1 — 0:bedrock-harness.
Reviewed diff is only the real dotCMS#36317 change (18 files); the test workflow + removal of other repo workflows live on the base branch.

Throwaway — do not merge.

[github-actions]

🤖 dotBot Review (Bedrock)

Reviewed 18 file(s); 12 candidate(s) → 7 confirmed, 0 uncertain (unverified, kept for review).

⚠️ Coverage capped: 0 file(s) + 54 lower-severity candidate(s) skipped (limits: 40 files, 12 candidates).

Confirmed findings

• 🟠 High core-web/libs/data-access/src/lib/dot-upload-file/dot-upload-file.service.spec.ts:24 — Test reliability issue due to mockReturnValueOnce usage
  The change from mockReturnValue to mockReturnValueOnce for dotErrorManagerService.handle will only mock the first error handling call. Subsequent error handler invocations in the same test will receive undefined behavior, breaking test cases that trigger multiple errors or require consistent error handling across multiple operations.
• 🟡 Medium core-web/libs/data-access/src/lib/dot-upload-file/dot-upload-file.service.spec.ts:37 — Insufficient FormData content validation in test
  The test uses jasmine.any(FormData) which only verifies type, not actual content structure. This allows tests to pass even if 'file' key is missing or incorrect in the FormData payload, creating false positive test results.
• 🟡 Medium core-web/libs/data-access/src/lib/dot-upload-file/dot-upload-file.service.spec.ts:45 — Missing error handling test coverage in uploadFile
  The test suite for uploadFile only verifies the success case via 'should upload file correctly' test. No tests exist for HTTP error scenarios (e.g. server errors, network failures), leaving error handling logic potentially untested.
• 🟡 Medium core-web/libs/data-access/src/lib/dot-upload-file/dot-upload-file.service.spec.ts:45 — Error test verifies message but not error type
  The test checks the error message string but does not validate the error object's structure/type matches real HttpErrorResponse objects from Angular HttpClient. This could miss regressions in error handling logic that depends on specific error properties beyond the message.
• 🟡 Medium core-web/libs/data-access/src/lib/dot-upload-file/dot-upload-file.service.spec.ts:42 — Missing URL assertion in HTTP POST test
  The test verifies the POST method was called but doesn't explicitly check the request URL. While the mock currently matches any URL, this could lead to false positives if the service starts making POST requests to other endpoints. The test should validate the specific API endpoint being used.
• 🟡 Medium core-web/libs/data-access/src/lib/dot-upload-file/dot-upload-file.service.ts:23 — Uncaught JSON.parse exception with invalid config values
  The code uses JSON.parse() without a try/catch block around it. If the parsed string is invalid JSON, this will throw an uncaught exception and crash the application flow. This is particularly risky when parsing configuration values that might come from external sources.
• 🔵 Low core-web/libs/data-access/src/lib/dot-upload-file/dot-upload-file.service.ts — No functional code changes detected
  The PR appears to be a test/workflow change only with no actual code modifications to the core system. The described changes relate to testing infrastructure and workflow cleanup rather than functional code changes that would introduce runtime issues.

---

_{us.deepseek.r1-v1:0 · Run: #28254068404 · tokens: in: 94901 · out: 59050 · total: 153951 · calls: 45}