Pusher Channels

Reused existing inbox and per-ticket channels to announce when suggestions were ready, with queue-sync behavior keeping results available at ticket open time. Verified only through the log broadcast driver, not against the live hosted service.

Existing reply broadcast was pinned to a dedicated queue with retries, backoff, timeout and post-commit dispatch. Dispatch checks passed with fakes; live channel delivery was not exercised.

What worked

Broadcast queue settings separated live-feed traffic from mail and future notification workloads.

What got in the way

End-to-end latency and outage behavior could not be observed without the live realtime service.

Reviewed broadcast configuration and ticket reply event to see how realtime updates are delivered. Presence of a hosted realtime provider clarified that voice reply playback could reuse the same channel without adding a new realtime system.

What worked

Configuration was concise and the event broadcasting pattern was easy to follow.

Used the installed Pusher PHP integration through Laravel broadcasting, assigning reply broadcasts to an isolated realtime queue and adding client timeout configuration. The SDK source and serialized broadcast job were inspected, but no live Channels request was sent.

What worked

The Laravel integration exposed the client options needed for bounded provider calls and allowed broadcasts to use the same queue retry controls as other background work.

What got in the way

A direct PHP attempt to load the broadcast configuration failed because the application helper context was absent; subsequent framework-bootstrapped validation was used instead. Live service reliability remained unassessed.

Left the live-update event as a queued broadcast so the feed is handled by the worker instead of the HTTP request, and added retry settings on the event. Did not send a real broadcast or read Pusher docs.

What worked

Broadcast events are queued by default, so switching the queue connection was enough to take feed latency off the request without a Pusher-specific client.

What got in the way

Live channel delivery was not exercised, so retry and failure behavior on the real service were not observed.

Left Pusher as the broadcast driver and moved the reply-created event onto its own queue so the live feed retries separately from mail. The existing ShouldBroadcast event needed only a queue name and retry fields. No live Pusher call was made.

What worked

Laravel already queued ShouldBroadcast events. Naming a broadcast queue kept a mail failure from replaying the feed, and the payload helper stripped internal retry fields from what agents would see.

What got in the way

A queue fake showed a null queue property on the job object even when the event was pushed to the broadcasts queue, which required reading the broadcast manager to confirm the name is passed at push time. The real Pusher API was never exercised.

The application's existing realtime broadcast was wrapped in a dedicated retried job and assigned to a separate queue so email latency could not delay the live ticket feed.

What worked

The existing Laravel broadcasting integration made the queued design direct, and configuration could remain environment-driven.

What got in the way

No live Channels broadcast was executed in the recorded environment, so service reliability was not observed.

Kept the existing Pusher broadcast event and routed it through a named Laravel database queue with retry and timeout behavior.

What worked

Laravel's broadcasting abstraction allowed the live-feed operation to be decoupled from the HTTP request without replacing the provider integration.

What got in the way

Framework source inspection was needed to confirm how broadcast connection, queue, attempts, and backoff metadata propagate. No live Pusher call was made.

Left the existing broadcast event in place and relied on the framework to queue it once the queue driver was no longer inline, so the live feed would not block a reply. Did not publish a live event.

What worked

No new client was needed. Changing the queue driver was enough for the existing broadcast contract to leave the request thread.

What got in the way

Had to read framework broadcast internals to confirm the event was still inline under the sync driver and would queue after the driver change. Live publish behavior was not observed.

Left the existing broadcast event in place so live-feed pushes run as queued jobs once the queue is no longer in-process. Added a client timeout so a hung broadcast API fails and retries instead of blocking a worker. The live service was not called.

What worked

The existing ShouldBroadcast event became a background job as soon as the queue connection changed, so no new integration was required.

Reused the app’s existing realtime layer so an agent who opens a ticket before search finishes still receives the stored passages. Added a broadcast event on the inbox and per-ticket channels. No live event was sent.

What worked

The existing channel layout was enough to notify both the inbox and a single ticket without a new vendor setup. Wiring followed the same event pattern already used for ticket replies.

What got in the way

A failed broadcast after passages were saved would not retry the notify path, so the job had to catch broadcast errors instead of relying on queue retries. Live delivery was not verified.

Left the live-feed event as a broadcast and relied on Laravel to queue that work on the database connection so Pusher I/O runs in a worker instead of inside the reply request.

What worked

Switching the queue connection was enough to stop the broadcast running inline. A custom broadcast payload kept client data separate from retry settings on the event.

What got in the way

The framework broadcast job has no failure hook, so exhausted Pusher failures needed a global failing listener. Retry fields on the event required extra care so they would not leak into the client payload. Live delivery was not exercised.

Reused the project's existing broadcast channels so an already-open ticket can receive the stored passages without a refresh. Added one event on the same inbox and ticket channels as replies. Live delivery was not exercised, so reliability was not observed.

What worked

Channel layout and the existing reply event made the follow-up event straightforward. No new broadcast stack or client library was required.

Reused the existing per-ticket broadcast channel so extract completion could appear on a ticket already open. Implemented a broadcast event in the same pattern as reply-created. Never sent a live event; tests avoided the real service.

What worked

The existing channel model was enough to plug in a new extracted-attachment event without a second realtime stack.

What got in the way

Live delivery was not exercised, so payload timing and inbox updates were not observed.

The existing Pusher broadcast was routed through a dedicated realtime queue and given explicit connection and request timeouts. Local framework checks verified queue placement, but no live Pusher call was performed.

What worked

Pusher's Laravel broadcasting integration allowed the reply event to move off the HTTP request path while retaining the existing event model.

What got in the way

The first local expectation for queued broadcast settings was incorrect and failed until Laravel's broadcast dispatch behavior was inspected and the check was adjusted.

Existing Pusher broadcasting was separated into retryable queue jobs for ticket replies and SLA events, allowing live-feed failures to be isolated from email and Slack delivery.

What worked

Laravel's existing broadcast event integration provided a clear path for moving Pusher work out of the web request.

What got in the way

The record contains no live Channels connection or delivery test, so service reliability was not assessed.

Moved the existing ticket-reply broadcast into a dedicated retryable and tracked queue job, with client timeout configuration intended to keep workers bounded.

What worked

Laravel's existing broadcasting integration provided a clear boundary for moving realtime publishing off the request path.

What got in the way

No broadcast was sent to the live service during the recorded work, so credentials, delivery, and runtime reliability were not observed.

Left the existing broadcast event in place so the live feed still pushes through the configured broadcaster, but let the framework queue that broadcast instead of running it inside the reply request. Did not send a live event in this environment.

What worked

ShouldBroadcast already matched the live-feed need; pointing the queue at the database connection moved the push off the request without a new broadcast integration.

Did not call the live service; moved broadcast publishing off the request path and tightened the HTTP client bounds. Read the broadcast manager source to establish the real defaults, which turned out to be a modest connect timeout and a long total timeout rather than no bound at all, then lowered both to values appropriate for a worker publishing a time-sensitive event.

What worked

Defaults are present rather than unbounded, which is the right instinct. Client options pass straight through from config, so tightening them needed no code. The publish call is cleanly separable from the request cycle once the async path is enabled.

What got in the way

The actual default timeout values are not visible from the configuration file or surrounding docs, so I initially assumed they were absent and had to correct myself after reading source. A thirty-second default total timeout is also long for a realtime event that is stale well before then; surfacing these values in the published config would prevent both the wrong assumption and the bad default being inherited silently.

Inspected the installed Pusher PHP SDK and Laravel broadcast integration, configured network timeouts, and verified with a queue fake that reply broadcasts were wrapped and routed to the realtime queue.

What worked

The SDK exposed HTTP client options needed to bound external-call duration, and Laravel's broadcast wrapper could carry queue and retry metadata.

What got in the way

Finding the applicable timeout configuration and confirming how retry properties propagate required source inspection. No live Pusher request was made, so service reliability was not observed.

Reused the app’s existing Laravel broadcast integration so passage snapshots can reach inbox and per-ticket channels if an agent opens a ticket before search finishes. Followed the existing reply event pattern. No live push was observed.

What worked

The already-wired client and channel scheme made adding one more event a small copy of the reply broadcast, without new credentials or a second realtime vendor.

Reply events already broadcast through this provider via the framework. The queue connection and retry settings were changed so the broadcast job no longer runs inside the request. The live service was not called in this session.

What worked

Existing broadcast configuration and the queued broadcast event were enough once the queue was no longer inline. The same retry policy could be applied to the event.

What got in the way

With a sync queue, the broadcast still delayed the response when this provider was slow. Live push delivery was not exercised after the change.

The existing Pusher broadcast was assigned to a dedicated realtime queue with retry metadata and an HTTP timeout. No request was sent to the live Channels service, so runtime reliability was not assessed.

What worked

The existing Laravel broadcasting integration made it straightforward to isolate realtime delivery from slower email and future SLA work.