test(deepseekr1): agentic review @beta.15 — us.deepseek.r1-v1:0

[wezell]

Clean single-model e2e at @v3.3.0-beta.15. Model: us.deepseek.r1-v1:0 — bedrock-harness. Reviewed diff = only the dotCMS#36317 change. Throwaway.

[github-actions]

🤖 dotBot Review (Bedrock)

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

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

Confirmed findings

• 🟠 High core-web/libs/portlets/dot-content-drive/portlet/src/lib/shared/models.ts:15 — Type definition mismatch in DotContentDriveUploadBaseType
  The type DotContentDriveUploadBaseType references 'baseType', but UPLOAD_SELECTOR_OPTIONS elements use 'contentType'. This mismatch leads to runtime errors when accessing undefined properties.
• 🟠 High core-web/libs/data-access/src/lib/dot-workflow-actions-fire/dot-workflow-actions-fire.service.ts:253 — Incorrect handling of 'inode' in EDIT action
  The request method moves 'inode' from the body to query parameters, which may cause the EDIT action to fail if the backend expects 'inode' in the body. The saveContentlet method (line 191) uses ActionToFire.EDIT and passes data that may include 'inode', leading to its removal from the request body.
• 🟡 Medium core-web/libs/data-access/src/lib/dot-upload-file/dot-upload-file.service.spec.ts:112 — Test does not verify contentType exclusion in newContentletByBaseType call
  The test 'should not pass a contentType to the fire service' only asserts that newContentlet() wasn't called, but doesn't validate parameters passed to newContentletByBaseType(). This leaves a gap in verifying contentType exclusion from the actual service call being made.
• 🟡 Medium core-web/libs/data-access/src/lib/dot-workflow-actions-fire/dot-workflow-actions-fire.service.spec.ts:150 — Missing Content-Type header assertion in FormData test
  The test does not verify that the Content-Type header starts with 'multipart/form-data' when submitting FormData. While Angular's HttpClient automatically sets this header, the test lacks an explicit assertion to guard against future code changes that might manually override headers (e.g., hardcoding 'application/json'). This creates a test gap for a critical file upload requirement.
• 🟡 Medium core-web/libs/data-access/src/lib/dot-upload-file/dot-upload-file.service.ts:58 — Original error details lost in uploadFile error handling
  In dot-upload-file.service.ts:58, the catchError operator throws a new generic Error('Error uploading file') while swallowing the original error object. This loses critical debugging information like HTTP status codes and server responses. The console.error only logs the generic message, not the actual error. Fix by preserving original error: throwError(() => error) or include error details in new Error.
• 🟡 Medium core-web/libs/portlets/dot-content-drive/portlet/src/lib/components/dialogs/dot-content-drive-dialog-upload-selector/dot-content-drive-dialog-upload-selector.component.html — Potential null dereference in template
  The template accesses file.name without safe navigation operator (?.), creating potential null reference errors if any file object is null/undefined or lacks name property
• 🟡 Medium core-web/libs/portlets/dot-content-drive/portlet/src/lib/components/dialogs/dot-content-drive-dialog-upload-selector/dot-content-drive-dialog-upload-selector.component.spec.ts:35 — Incorrect test assertion for dialog closure
  The test asserts that dialogRef.close is called with files, but the component's onUploadFiles method emits uploadFiles event and closes dialog without parameters. Production code closes dialog without arguments, making the test assertion invalid.

🔎 Uncertain (could not confirm or disprove — review manually)

• 🟡 Medium core-web/libs/portlets/dot-content-drive/portlet/src/lib/shared/constants.ts:94 — Potential case mismatch in DotCMSBaseTypesContentTypes usage
  The enum's actual string values could not be verified from available data. If DotCMSBaseTypesContentTypes.FILEASSET/DOTASSET enum members don't exactly match backend expectations (e.g. 'FileAsset' vs 'fileasset'), upload functionality may break. Requires checking the enum's definition to confirm string values match API requirements.
• 🟡 Medium core-web/libs/data-access/src/lib/dot-workflow-actions-fire/dot-workflow-actions-fire.service.spec.ts:120 — Potential missing contentType in API request test assertion
  The test asserts contentType is undefined when using baseType, but without direct API documentation or service implementation review, it's unclear if the backend requires contentType parameter. The assertion might be correct if the API uses baseType exclusively, but could mask a regression if the endpoint expects either parameter.

---

_{us.deepseek.r1-v1:0 · Run: #28255167192 · tokens: in: 81921 · out: 38681 · total: 120602 · calls: 40 · est. ~$0.319}

[github-actions]

🟠 [High] Type definition mismatch in DotContentDriveUploadBaseType

The type DotContentDriveUploadBaseType references 'baseType', but UPLOAD_SELECTOR_OPTIONS elements use 'contentType'. This mismatch leads to runtime errors when accessing undefined properties.