36267 publishing api include scheduled bundles in apiv1publishing

[hassandotcms]

Include scheduled bundles in GET /api/v1/publishing (resolves #36267)

Problem

/api/v1/publishing only reads publishing_queue_audit. Bundles pushed with a future publish date have no audit row until the cron picks them up, so they were invisible to the API (the legacy JSP Queue tab showed them by reading publishing_queue directly).

Change

Surface those bundles through the existing endpoints as a new SCHEDULED status — no new endpoint.

• PublishAuditStatus.Status: add SCHEDULED (negative sentinel code, never persisted).
• PublisherAPI: add countScheduledBundleIds / getScheduledBundleIds — queue rows with publish_date IS NOT NULL and no audit row (excludes drafts); asset count from queue rows,
  env count via correlated subquery.
• GET /api/v1/publishing: unions the scheduled tier with the audit tier as a contiguous block; pagination total and slicing stay exact. ?status=SCHEDULED filters to that tier;
  mixed filters work.
• GET /api/v1/publishing/{id}: returns a synthesized SCHEDULED detail instead of 404.
• DELETE /api/v1/publishing/purge?status=SCHEDULED: rejected (audit-based purge can't match it; points to per-bundle DELETE).
• Views: add nullable scheduledPublishDate (future run time) so createDate keeps its meaning.
• Regenerated openapi.yaml.

Tests

Integration tests in PublishingResourceIntegrationTest using the real push path: visibility/status, status filter (single + mixed), pagination total, detail-not-404, delete-cancels, transition to WAITING_FOR_PUBLISHING once an audit row appears, and a legacy-getQueueBundleIds-vs-API parity check.

[claude]

Claude finished @hassandotcms's task in 1m 44s —— View job

---

Rollback Safety Analysis

• Read rollback-unsafe categories reference
• Get full PR diff
• Analyze diff against all unsafe categories
• Post findings

---

Result: Pull Request Unsafe to Rollback

• Category: M-3 — REST / GraphQL / Headless API Contract Change

• Risk Level: 🟡 MEDIUM

• Why it's unsafe: This PR adds a new SCHEDULED enum value to PublishAuditStatus.Status that flows into the status field of REST responses (/api/v1/publishing and /api/v1/publishing/{id}). It also adds a new nullable scheduledPublishDate (Instant) field to both PublishingJobView and PublishingJobDetailView. Once N is deployed, clients that adapt to these new fields or the SCHEDULED status will break on rollback to N-1: the SCHEDULED status never appears (those scheduled bundles silently become invisible), and scheduledPublishDate is absent from all responses. The Angular admin and any API consumer that renders or logic-branches on SCHEDULED will regress.

• Code that makes it unsafe:

  • dotCMS/src/main/java/com/dotcms/publisher/business/PublishAuditStatus.java — SCHEDULED(-1) added to Status enum; flows through REST response status field serialization
  • dotCMS/src/main/java/com/dotcms/rest/api/v1/publishing/AbstractPublishingJobView.java — new @Nullable Instant scheduledPublishDate() accessor on the Immutables interface
  • dotCMS/src/main/java/com/dotcms/rest/api/v1/publishing/AbstractPublishingJobDetailView.java — same scheduledPublishDate() addition
  • dotCMS/src/main/webapp/WEB-INF/openapi/openapi.yaml — SCHEDULED added to all three status enum schemas; scheduledPublishDate property added to PublishingJobDetailView and PublishingJobView components

• Alternative (if possible): Since scheduledPublishDate is @Nullable and clients that never saw SCHEDULED bundles before will simply not see them after a rollback (same pre-N behavior), the practical blast radius is narrow — clients degrade gracefully back to the N-1 behavior as long as they handle unknown enum values and missing fields defensively. To harden this formally: treat the N release as phase 1 (additive-only); ensure the Angular admin and documented API consumers code SCHEDULED and scheduledPublishDate as optional/unknown-tolerant before relying on them in phase 2 (N+1).

---

Scope of this review: Checked against all categories (C-1 through C-4, H-1 through H-8, M-1 through M-4). No database migrations, Elasticsearch mapping changes, bundle XML format changes, or OSGi interface breaks were detected. The only rollback-unsafe category is M-3 above.

[github-actions]

🤖 Bedrock Review — deepseek.v3.2

[🟠 High] dotCMS/src/main/java/com/dotcms/publisher/business/PublisherAPIImpl.java:671 — SQL injection risk: SQLUtil.sanitizeParameter is not a safe substitute for parameterized queries. The filter string is concatenated into the SQL string before being passed to DotConnect.setSQL(). This bypasses the protection of addParam(). Use ? placeholders and addParam for all dynamic values.

[🟠 High] dotCMS/src/main/java/com/dotcms/publisher/business/PublisherAPIImpl.java:715 — SQL injection risk: Same issue as above. The filter string is concatenated into the SQL string. Use ? placeholders and addParam for all dynamic values.

[🟡 Medium] dotCMS/src/main/java/com/dotcms/rest/api/v1/publishing/PublishingResource.java:265 — Potential NullPointerException: statusList may be null if parseStatuses returns null. The stream operation statusList.stream() will throw. Ensure parseStatuses never returns null or add a null check.

[🟡 Medium] dotCMS/src/main/java/com/dotcms/rest/api/v1/publishing/PublishingResource.java:268 — Logic error: When statusFilterProvided is true and statusList contains only SCHEDULED, auditStatusList becomes empty. wantsAudit is set to false because !auditStatusList.isEmpty() is false. However, the audit tier should still be queried if the status filter includes other statuses besides SCHEDULED. The current logic incorrectly excludes the audit tier when the filter is something like ?status=SCHEDULED,SUCCESS because auditStatusList would contain SUCCESS and wantsAudit would be true. Wait, the logic is: final boolean wantsAudit = !statusFilterProvided || !auditStatusList.isEmpty();. If statusFilterProvided is true and auditStatusList is empty (e.g., only SCHEDULED), then wantsAudit is false. That's correct—we don't want audit rows. If statusFilterProvided is true and auditStatusList is not empty (e.g., SCHEDULED,SUCCESS), then wantsAudit is true. That's also correct. So the logic is fine. However, there is a subtle bug: auditStatusList is derived from statusList, but statusList may include SCHEDULED and other statuses. The filtering of SCHEDULED is correct. No bug here.

[🟡 Medium] dotCMS/src/main/java/com/dotcms/rest/api/v1/publishing/PublishingResource.java:277 — Off-by-one error: offset is zero-based, but the condition offset < scheduledTotal is correct. However, the calculation scheduledLimit = Math.min(perPage, scheduledTotal - offset) may produce a negative value if offset > scheduledTotal. This is prevented by the if condition, but if offset equals scheduledTotal, scheduledTotal - offset is zero, and Math.min(perPage, 0) is zero, leading to an empty query. That's fine. No bug.

[🟡 Medium] dotCMS/src/main/java/com/dotcms/rest/api/v1/publishing/PublishingResource.java:284 — Incorrect audit offset calculation: auditOffset = Math.max(0, offset - scheduledTotal). This is correct when offset is within or beyond the scheduled tier. However, if offset is less than scheduledTotal, we already fetched some scheduled rows, and the audit offset should be 0. The Math.max ensures it's not negative. That's fine.

[🟡 Medium] dotCMS/src/main/java/com/dotcms/rest/api/v1/publishing/PublishingJobsHelper.java:293 — Potential NumberFormatException: Integer.parseInt(value.toString()) may throw if value.toString() is not a valid integer. The method asInt is used on asset_count and environment_count from SQL results, which should be numbers, but defensive coding is lacking. Consider catching NumberFormatException and returning 0.

[🟡 Medium] dotCMS/src/main/java/com/dotcms/rest/api/v1/publishing/PublishingJobsHelper.java:454 — Missing null check: element.getPublishDate() could be null, but the stream filter already checks for non-null. However, scheduledElements.get(0).getPublishDate() could throw IndexOutOfBoundsException if scheduledElements is empty. The method returns null in that case, but the call to getPublishDate is after the empty check? Wait: the code does if (scheduledElements.isEmpty()) { return null; } then final Instant scheduledDate = toInstant(scheduledElements.get(0).getPublishDate());. This is safe because scheduledElements is not empty. However, getPublishDate could still return null? The filter element.getPublishDate() != null ensures it's not null. So safe.

[🟡 Medium] dotCMS/src/main/java/com/dotcms/rest/api/v1/publishing/PublishingJobsHelper.java:460 — Potential NullPointerException: scheduledElements.stream().map(PublishQueueElement::getEnteredDate) may contain null values. The filter(Objects::nonNull) is missing. Actually, there is filter(java.util.Objects::nonNull)? Wait, the code shows filter(java.util.Objects::nonNull). Yes, it's there. It's safe.

[🟡 Medium] dotCMS/src/main/java/com/dotcms/rest/api/v1/publishing/PublishingJobsHelper.java:497 — Missing permission check: environmentAPI.findEnvironmentsByBundleId(bundleId) may return environments the current user doesn't have permission to see. The method buildConfiguredEnvironmentDetails is used in toScheduledJobDetailView, which is called from a REST endpoint. The endpoint should enforce permissions, but the helper method does not. However, the existing toPublishingJobDetailView also doesn't check permissions? It uses environmentAPI which may filter by permission? Need to verify. This could be a security gap.

[🟡 Medium] dotCMS/src/main/java/com/dotcms/rest/api/v1/publishing/PublishingJobsHelper.java:534 — Potential NullPointerException: endpoint.getServerName() returns an Object? The code calls toString() on it. If getServerName() returns null, toString() will throw. Use Objects.toString(endpoint.getServerName(), endpoint.getId()) instead.

[🟡 Medium] dotCMS/src/main/java/com/dotcms/rest/api/v1/publishing/PublishingResource.java:985 — Inconsistent error handling: The purge endpoint rejects SCHEDULED status with a BadRequestException. However, the delete endpoint (DELETE /api/v1/publishing/{bundleId}) should handle SCHEDULED bundles. Does it? The delete method uses publishAuditAPI.getPublishAuditStatus and if null, it tries to cancel the bundle via PublisherAPI.deleteBundleFromQueue. That should work for scheduled bundles. But the purge endpoint says to cancel individually, which is correct. However, the error message says "Cancel a scheduled bundle individually via DELETE /api/v1/publishing/{bundleId}." That's accurate. No bug.

[🟡 Medium] dotCMS/src/main/java/com/dotcms/publisher/business/PublisherAPIImpl.java:655 — SQL concatenation for SCHEDULED_BUNDLES_FILTER: The filter condition is appended as a string, not using ? placeholder. This is the same injection issue as above, but it's in a constant string. Actually, SCHEDULED_BUNDLES_FILTER contains ? placeholders? Wait, it's "AND (LOWER(pq.bundle_id) LIKE ? OR LOWER(pb.name) LIKE ?) ". That's fine. The issue is that in countScheduledBundleIds and getScheduledBundleIds, they append SCHEDULED_BUNDLES_FILTER to the SQL string, which includes ?. Then they call dc.addParam. That's correct. The earlier finding about SQLUtil.sanitizeParameter is wrong? Let's re-examine: In countScheduledBundleIds, they do:

if (hasFilter) {
    sql.append(SCHEDULED_BUNDLES_FILTER);
}
...
if (hasFilter) {
    final String likeParam = "%" + SQLUtil.sanitizeParameter(filter).toLowerCase() + "%";
    dc.addParam(likeParam);
    dc.addParam(likeParam);
}

The SCHEDULED_BUNDLES_FILTER contains ? placeholders, and they call addParam. That's safe. However, they use `SQLUtil.s

---

_{Run: #28037149646 · tokens: in: 11791 · out: 2048 · total: 13839}

[semgrep-code-dotcms-test]

Semgrep found 7 CUSTOM_INJECTION-2 findings:

• dotCMS/src/main/java/com/dotcms/publisher/business/PublisherAPIImpl.java
  • L694-701 - Triage
  • L694-700 - Triage
  • L694-699 - Triage
  • L694-698 - Triage
  • L694-697 - Triage
  • L694-696 - Triage
  • L694-695 - Triage

The method identified is susceptible to injection. The input should be validated and properly
escaped.

If this is a critical or high severity finding, please also link this issue in the #security channel in Slack.

[github-actions]

🤖 Bedrock Review — us.deepseek.r1-v1:0

New Issues

• 🟡 Medium: dotCMS/src/main/java/com/dotcms/publisher/business/PublisherAPIImpl.java:697 — Redundant COALESCE on publish_date when WHERE clause ensures pq.publish_date IS NOT NULL. While functionally harmless, MAX(pq.publish_date) alone would suffice, avoiding unnecessary fallback to pb.publish_date which could be stale/null. Simplification improves clarity.
• 🟡 Medium: dotCMS/src/main/java/com/dotcms/publisher/business/PublisherAPIImpl.java:700 — Unnecessary COALESCE for entered_date since publishing_queue.entered_date is non-null in schema. MAX(pq.entered_date) alone is sufficient, making the fallback to publish_date redundant.

---

_{Run: #28068556478 · tokens: in: 12450 · out: 1630 · total: 14080}

[claude]

Pull Request Unsafe to Rollback!!!

• Category: M-3 — REST / GraphQL / Headless API Contract Change
• Risk Level: 🟡 MEDIUM
• Why it's unsafe: The PR adds a new SCHEDULED enum value to the PublishAuditStatus.Status enum that is serialized in REST response payloads (via the status field on PublishingJobView and PublishingJobDetailView). It also adds a new nullable field scheduledPublishDate (of type Instant) to both AbstractPublishingJobView and AbstractPublishingJobDetailView. After N deploys, clients (including the Angular admin) may receive responses containing "status": "SCHEDULED" and "scheduledPublishDate": "..." — shapes that N-1 does not know about. If rolled back to N-1, clients that have adapted to these new fields will encounter a broken contract: SCHEDULED status will never appear (those bundles silently disappear from the list), and scheduledPublishDate will be absent from all responses.
• Code that makes it unsafe:
  • dotCMS/src/main/java/com/dotcms/rest/api/v1/publishing/AbstractPublishingJobView.java — new scheduledPublishDate() method added to the Immutables interface, line 165+
  • dotCMS/src/main/java/com/dotcms/rest/api/v1/publishing/AbstractPublishingJobDetailView.java — same addition, line 133+
  • dotCMS/src/main/java/com/dotcms/publisher/business/PublishAuditStatus.java — SCHEDULED(-1) added to Status enum; this value flows through all status serialization in the REST layer (line 60)
  • dotCMS/src/main/webapp/WEB-INF/openapi/openapi.yaml — SCHEDULED added to all three status enum schemas; scheduledPublishDate property added to both PublishingJobDetailView and PublishingJobView components
• Alternative (if possible): Apply the standard two-phase contract change. In release N, add scheduledPublishDate and SCHEDULED to the schema but treat them as additive-only extensions clients should treat as optional. Ensure that the Angular admin and any documented API consumers are coded defensively (null/unknown value handling) so that a rollback to N-1 — where SCHEDULED bundles are absent and scheduledPublishDate is not returned — degrades gracefully rather than breaking the UI or consumers. In practice, since scheduledPublishDate is @Nullable and N-1 consumers that never saw SCHEDULED bundles before will simply show none after rollback, the real-world impact is narrow — scheduled bundles become invisible again, same behavior as before N was deployed.

[jcastro-dotcms]

There's a com.dotmarketing.util.DateUtil class in core. Please move this method to that class of check if the method already exists there.

[hassandotcms]

done

[jcastro-dotcms]

There's a com.dotmarketing.util.NumberUtil class in core. Please move this method to that class of check if the method already exists there.

[hassandotcms]

done

[github-actions]

🤖 Bedrock Review — qwen.qwen3-next-80b-a3b

New Issues

• 🔴 Critical: dotCMS/src/main/java/com/dotcms/publisher/business/PublishAuditStatus.java:49 — Introducing SCHEDULED(-1) as a synthetic status code risks collision if the database ever uses negative status codes; this violates the assumption that status codes are strictly positive 1–18 and breaks any code relying on status > 0 or status >= 1 (e.g., legacy UIs, queries, or validation logic). This is a silent data corruption hazard.
• 🔴 Critical: dotCMS/src/main/java/com/dotcms/publisher/business/PublisherAPIImpl.java:652 — SQLUtil.sanitizeParameter(filter).toLowerCase() is applied to user input before addParam(), but SQLUtil.sanitizeParameter() does not escape % or _ wildcards — this allows SQL injection via filter parameter when used in LIKE clauses. Example: filter = "foo\%"; becomes LIKE '%foo%%' — attacker can inject foo\% OR 1=1 to bypass filter. Must use DotConnect.addParam() with ? placeholders and never interpolate sanitized strings into SQL.
• 🔴 Critical: dotCMS/src/main/java/com/dotcms/rest/api/v1/publishing/PublishingResource.java:273 — getScheduledBundleIds(scheduledLimit, offset, filter) is called with filter directly from HTTP query, but filter is never validated for length or allowed characters. Combined with the above SQL injection flaw, this enables full DB compromise. No input sanitization or validation layer exists.
• 🔴 Critical: dotCMS/src/main/java/com/dotcms/rest/api/v1/publishing/PublishingJobsHelper.java:200 — toScheduledJobView() uses DateUtil.asDate(row.get("publish_date")) on a Map<String, Object> from DotConnect.loadObjectResults(). If the column returns null, asDate() returns null, but toInstant() is called unconditionally — this throws NullPointerException and crashes the API endpoint. No null check before toInstant().
• 🔴 Critical: dotCMS/src/main/java/com/dotcms/rest/api/v1/publishing/PublishingJobsHelper.java:285 — toScheduledJobDetailView() calls getQueueElementsSafely(bundleId) and uses scheduledElements.get(0).getPublishDate() without checking scheduledElements.size() > 0. This throws IndexOutOfBoundsException if scheduledElements is empty (e.g., due to DB timeout or race condition), crashing the endpoint.
• 🟠 High: dotCMS/src/main/java/com/dotcms/publisher/business/PublisherAPIImpl.java:642 — countScheduledBundleIds() uses Integer.parseInt(dc.loadObjectResults().get(0).get("bundle_count").toString()) — if the result set is empty (e.g., due to DB error or no matching rows), get(0) throws IndexOutOfBoundsException, which is caught and wrapped in DotPublisherException, but the root cause is lost. Must check !dc.loadObjectResults().isEmpty() before indexing.
• 🟠 High: dotCMS/src/main/java/com/dotcms/publisher/business/PublisherAPIImpl.java:693 — getScheduledBundleIds() uses dc.setMaxRows(limit); dc.setStartRow(offset); — if offset is negative or limit is negative, this may cause DB driver errors or undefined behavior. No validation of limit/offset bounds.
• 🟠 High: dotCMS/src/main/java/com/dotcms/rest/api/v1/publishing/PublishingResource.java:286 — getPublishAuditStatus(remaining, auditOffset, ...) is called with auditOffset = Math.max(0, offset - scheduledTotal) — if offset is huge (e.g., 10M), auditOffset may exceed DB max offset, causing silent truncation or performance degradation. No validation or cap on offset.
• 🟡 Medium: dotCMS/src/main/java/com/dotcms/publisher/business/PublisherAPIImpl.java:652 — SQLUtil.sanitizeParameter(filter).toLowerCase() is applied to user input, but SQLUtil.sanitizeParameter() is not documented to escape SQL wildcards — this is a security anti-pattern. Assumption: SQLUtil.sanitizeParameter() only escapes quotes, not %/_. What to verify: Check SQLUtil.sanitizeParameter() source — if it doesn’t escape % and _, this is a critical SQLi vector.
• 🟡 Medium: dotCMS/src/main/java/com/dotcms/rest/api/v1/publishing/PublishingJobsHelper.java:200 — toInstant(DateUtil.asDate(row.get("publish_date"))) — if row.get("publish_date") is a Timestamp, asDate() returns it, but toInstant() may lose precision if the underlying DB column is TIMESTAMP(3) and Java Date truncates to milliseconds. This is a data integrity risk. What to verify: Confirm publish_date column precision and whether Date loss is acceptable.
• 🟡 Medium: dotCMS/src/main/java/com/dotcms/rest/api/v1/publishing/PublishingResource.java:273 — getScheduledBundleIds(scheduledLimit, offset, filter) is called with filter from HTTP without validation — this allows DOS via extremely long strings (e.g., 100KB filter). No length limit on filter parameter. What to verify: Check if filter is capped in API contract or frontend.

Existing

• 🟡 Medium: dotCMS/src/main/java/com/dotcms/publisher/business/PublisherAPIImpl.java:697 — Redundant COALESCE on publish_date when WHERE clause ensures non-null (still present — unchanged)
• 🟡 Medium: dotCMS/src/main/java/com/dotcms/publisher/business/PublisherAPIImpl.java:700 — Unnecessary COALESCE for entered_date when column is non-null (still present — unchanged)

Resolved

• ✅ dotCMS/src/main/java/com/dotcms/publisher/business/PublishAuditStatus.java:49 — The SCHEDULED(-1) enum value was introduced, but the prior finding about redundant COALESCEs is unrelated and unchanged — this is not a resolution, it's a new issue. No resolved items.

---

_{Run: #28107677140 · tokens: in: 12460 · out: 2280 · total: 14740}