fix(content-api): guard against null ContentType in StoryBlock refresh path (#33645)

[gortiz-dotcms]

Summary

Contentlet.getContentType() performs a DB/cache lookup on every call and can return null when the content-type cache is transiently invalidated — most commonly during a push-publish bundle import, which calls ContentTypeCache2Impl.remove() for each updated type.

Three call sites used the method in a TOCTOU pattern: the first call served as a null guard, but the second call (inside the branch body) could race against the cache invalidation and return null, producing an NPE. Because ContentUtils.pull() wraps conAPI.search() with a catch (Throwable) that swallows all exceptions and returns an empty list, the NPE was silent — the content API returned {"contentlets":[]} with only a WARN util.ContentUtils - null log entry.

Changes

Call getContentType() once per code path, store the result in a local variable, and null-guard before accessing any method on it.

File	Change
ESContentFactoryImpl.processCachedContentlet()	Two calls collapsed to one cached local variable
StoryBlockAPIImpl.refreshReferences()	Three calls collapsed to one cached local variable
PushPublishigDependencyProcesor.processStoryBockDependencies()	Added null guard before hasStoryBlockFields() — was unconditional; most likely to NPE during push-publish since cache invalidation happens on that same thread

Regression Analysis

• No behavioral change for contentlets with a resolvable content type — the same checks pass as before
• Contentlets whose content type is null (deleted or orphaned) are now safely skipped instead of throwing NPE
• All existing StoryBlockAPITest integration tests remain valid; the fix only closes the null-dereference gap

Closes #33645

Test plan

• Verify the content API returns results (not an empty array) under concurrent push-publish activity
• Confirm no regressions in StoryBlock field rendering for normal content
• Check that push-publish dependency analysis completes without NPE when processing StoryBlock contentlets

[github-actions]

🤖 dotBot Review (Bedrock)

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

✅ No issues found after verification.

---

_{us.deepseek.r1-v1:0 · Run: #28516485849 · tokens: in: 10527 · out: 3734 · total: 14261 · calls: 4 · est. ~$0.034}

[claude]

Claude finished @gortiz-dotcms's task in 2m 5s —— View job

---

🔍 dotCMS Backend Review

• Load dotCMS conventions
• Get the Java diff
• Run specialized sub-agent reviews (Security, Database, Java Standards, REST API)
• Consolidate findings and post review

All four review dimensions (Security, Database, Java Standards, REST API) returned no findings. The fix correctly collapses multiple getContentType() calls into a single cached local variable and adds the missing null guard in PushPublishigDependencyProcesor — no behavioral changes for valid contentlets, no new issues introduced.

[claude]

✅ dotCMS Backend Review: no issues found.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request