Push Publishing: unreachable endpoint stalls the queue; bundle pushed now shows as Scheduled with old date

Problem Statement

Two independent defects in sender-side Push Publishing. Both are visible in the Publishing Queue portlet (Beta and legacy, which read the same tables).

1. One unreachable endpoint stalls every other bundle.
The push-publish HTTP client has no connect timeout, so a bundle whose endpoint does not answer blocks the publisher job for about two minutes per attempt. The job is single-threaded, so every bundle pushed after it waits; bundles pushed for "now" have been processed 10 to 19 minutes late. Any unexpected exception in one bundle also ends the whole run.

2. A bundle pushed for "now" is shown as Scheduled with an old date.
GET /api/v1/publishing reports every bundle that is queued but not yet picked up as SCHEDULED, whether its publish date is in the future or already due, and uses the date the assets were added to the draft bundle as createDate. A bundle created weeks ago and pushed today with the default publish date shows status Scheduled, a weeks-old Date Entered, and a detail line Scheduled for <push time>. Normally invisible because the job picks the bundle up in about two seconds; with problem 1 it lasts minutes.

Steps to Reproduce

1. Create environment TEST with one enabled endpoint whose connection attempts get no answer (a firewalled or non-routable address).
2. Push bundle A to TEST with the default publish date.
3. Within a few seconds push bundle B (any environment) whose assets were added to the bundle days earlier.
4. Refresh the Publishing Queue for several minutes; open View details on B.

Expected

• A fails within seconds with a connection error. B is picked up within seconds of its publish time.
• While B waits it is reported as requested, its Date Entered is the push time, and no "Scheduled for" date is shown.

Actual

• A shows Sending for about two minutes per attempt, three attempts, plus the same wait on every status poll of A.
• B shows Scheduled with the old draft date and "Scheduled for <push time>" until the job reaches it, minutes later.

Fix scope (backend only)

• F1 A connect timeout on the HTTP clients created in PushPublisher (bundle upload) and PublisherQueueJob (status poll), configurable via Config, default about 10 s. Only the TCP handshake wait is bounded.
• F2 In PublisherQueueJob, any throwable while processing one bundle finalizes that bundle (failed status with message, queue rows removed, one transaction) and processing continues with the next bundle.
• F3 In the v1 API, a queued bundle whose publish_date <= now is reported as BUNDLE_REQUESTED with createDate = publish_date and no scheduledPublishDate. Future-dated bundles keep SCHEDULED. The status filter follows the same split. No DB write.

Acceptance Criteria

• AC-001 With an endpoint whose TCP handshake never completes, a pushed bundle reaches FAILED_TO_SEND_TO_ALL_GROUPS within the configured connect timeout plus 15 s, with the endpoint message naming the timeout.
• AC-002 In that setup, a bundle pushed 7 s later to a healthy or refused endpoint has its audit row within 30 s of its publish date, and the job keeps running every minute.
• AC-003 A runtime exception while processing one bundle fails that bundle with the message recorded and its queue rows removed; remaining bundles in the same run are still processed.
• AC-004 A bundle pushed with publishDate = now whose assets were added earlier is returned by GET /api/v1/publishing and GET /api/v1/publishing/{id} as BUNDLE_REQUESTED, with createDate within 5 s of the push time and scheduledPublishDate = null, until the job picks it up.
• AC-005 A bundle pushed with publishDate one hour ahead is returned as SCHEDULED with scheduledPublishDate set, as today. ?status=SCHEDULED returns only future-dated bundles; ?status=BUNDLE_REQUESTED includes due, not-yet-picked-up bundles.
• AC-006 Existing push-publishing integration tests stay green; a push to a healthy receiver behaves as before.
• Verification: two new integration tests in dotcms-integration, registered in a MainSuite: one for AC-001 to AC-003 using an endpoint whose handshake never completes (saturated ServerSocket backlog or non-routable address) with a short configured connect timeout; one for AC-004 and AC-005 with a backdated entered_date.

dotCMS Version

main (also seen on a 1.0.0-SNAPSHOT build of 2026-08-31).

Severity

High - Major functionality broken

Links

• Related, same stall class with other triggers: #36343, #35764, #35999
• Spec: specs/37449-publishing-queue-dead-endpoint/spec.md
• Freshdesk: NA