test(glm5): agentic review — zai.glm-5

[wezell]

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

Model: zai.glm-5 — 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) → 1 confirmed, 8 uncertain (unverified, kept for review).

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

Confirmed findings

• 🟡 Medium dotCMS/src/main/java/com/dotcms/contenttype/business/DotAssetBaseTypeToContentTypeStrategyImpl.java:34 — Silent exception swallowing with no logging
  DotDataException and DotSecurityException are caught and silently return Optional.empty() with no logging - failures are invisible to operators and debuggers.

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

• 🟠 High dotCMS/src/main/java/com/dotcms/contenttype/business/DotAssetBaseTypeToContentTypeStrategyImpl.java:31 — Potential NPE if user or host are null
  Cannot verify in sandbox (bwrap errors), but the concern is plausible: if user or currentHost are extracted without null checks and passed to tryMatch which dereferences them, NPE would occur. Need to verify: (1) can getUser() or getCurrentHost() return null in any codepath, (2) does tryMatch dereference user/host without null guards. If both are true, this is a confirmed High-severity bug.
• 🟡 Medium dotCMS/src/main/java/com/dotcms/contenttype/business/DotAssetBaseTypeToContentTypeStrategyImpl.java:30 — Potential ClassCastException from unchecked contextMap casts
  Cannot verify the actual code due to sandbox limitations preventing file reads. The concern about unchecked casts from a Map<String,Object> to specific types (User, Host, List, etc.) is plausible and would cause ClassCastException if caller provides wrong types, but I cannot confirm the exact implementation without seeing the actual code.
• 🟡 Medium dotCMS/src/main/java/com/dotcms/contenttype/business/BaseTypeMimeTypeMatcher.java:53 — Potential NPE on currentHost parameter
  Unable to verify due to sandbox limitations. The suspected issue is that currentHost is used without null check in isSystemHostOrCurrentHost (line 53) and passed to match() without validation. If null, currentHost.getIdentifier() will throw NPE. Need to verify: (1) the actual code at line 53, (2) whether callers of this method can pass null, and (3) whether there are existing null checks elsewhere in the call chain.
• 🟡 Medium dotCMS/src/main/java/com/dotcms/contenttype/business/DotAssetBaseTypeToContentTypeStrategyImpl.java:55 — Unchecked cast on assetValue
  Cannot verify the code structure due to sandbox limitations (bwrap errors prevented file access). The reported concern about unchecked cast to File in else branch warrants verification: if the if branch guards with instanceof check, the else branch cast could cause ClassCastException at runtime if assetValue is neither File nor String. Need to verify the actual code structure to confirm if this is a real issue or if the else branch is truly unreachable.
• 🟡 Medium dotCMS/src/main/java/com/dotcms/contenttype/business/FileAssetBaseTypeToContentTypeStrategyImpl.java:43 — Potential null pointer dereference on currentHost
  Unable to verify the null-check status of currentHost before passing to mimeTypeMatcher.match() due to sandbox limitations preventing file access. The concern is plausible: if contextMap.get("currentHost") returns null and is cast without validation, it could cause NPE. Manual review needed to confirm whether null-check exists or if the value is guaranteed non-null by contract.
• 🟡 Medium dotCMS/src/main/java/com/dotcms/contenttype/business/FileAssetBaseTypeToContentTypeStrategyImpl.java:56 — Silent exception handling may hide real problems
  Cannot verify the actual code due to sandbox limitations. The suspected issue is that catching DotDataException | DotSecurityException and returning Optional.empty() without logging may hide real failures (permission issues, data corruption, DB errors). If this is accurate, callers cannot distinguish between 'legitimately not found' and 'error occurred'. Recommend adding Logger.warn() before returning empty, or rethrowing as RuntimeException.
• 🟡 Medium core-web/libs/data-access/src/lib/dot-upload-file/dot-upload-file.service.ts:1 — Cannot verify suspected issue — sandbox limitations
  Unable to read the file or diff due to sandbox network/filesystem restrictions. Cannot confirm or refute the suspected issue in dot-upload-file.service.ts. The PR title indicates this is a test of the agentic reviewer itself (throwaway PR), not a real code change to review.
• 🟡 Medium dotCMS/src/main/java/com/dotcms/contenttype/business/BaseTypeToContentTypeStrategyResolver.java — Cannot verify suspected issue - diff not provided
  The PR diff was not included in the prompt, and the suspected issue description is empty. Cannot confirm or refute without seeing the actual code changes in BaseTypeToContentTypeStrategyResolver.java

---

_{zai.glm-5 · Run: #28252594738 · tokens: in: 94581 · out: 4721 · total: 99302 · calls: 54}

[github-actions]

🤖 dotBot Review (Bedrock)

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

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

✅ No issues found after verification.

---

_{zai.glm-5 · Run: #28254070253 · tokens: in: 137269 · out: 10940 · total: 148209 · calls: 59}

[github-actions]

🟠 [High] Potential NPE if user or host are null

At lines 31-32, user and currentHost are extracted from contextMap without null checks. These are passed to tryMatch(file, currentHost, user) at line 42. In DotAssetAPIImpl.tryMatch (line 26), it calls getMimeType(file) which can throw if file operations fail, and then calls the overloaded tryMatch(mimeType, currentHost, user). If user or currentHost are null and the implementation dereferences them (e.g., for permission checks via hasPermission), this will cause NPE. The try-catch at lines 43-45 catches DotDataException and DotSecurityException but not NullPointerException, which would propagate up.