What's new in 3.8.1 (May 29, 2026): GunBroker listing gap recovery. Active listings had flatlined well below the number of in stock products eligible to list. Root cause was a combination of an over b

Released May 29, 2026. GunBroker listing gap recovery. Active listings had flatlined well below the number of in stock products eligible to list. Root cause was a combination of an over broad catch all stability gate plus queue processors that ate their own error messages, making the actual blockers invisible.

Catch All Stability Gate Refined

cron/sync_gunbroker_parallel.php Phase 1.6 , The 2026-05-05 OOS cooldown gate (added after a zombie listing incident) used a blanket 24h block on any product with a recent OOS kill. A routine catalog refresh on the distributor catalog server triggered mass OOS kills on transient stock drops, which then blocked 20,039 of 26,056 unlisted products (77% of the gap) for a full day. New gate requires BOTH conditions to block:, ends_at > NOW() - INTERVAL 4 HOUR (was 24h), COALESCE(oos_kill_attempts, 0) >= 2 (actual chronic flicker on the same gb_item_id) After the change: catch all eligibility went from 3,764 → 23,696 immediately. Of the 20,039 previously blocked, ZERO had oos_kill_attempts >= 2 , confirming they were catalog refresh artifacts, not real flicker.

Queue Processor Error Capture + Retry Fix

cron/process_gunbroker_queue.php + cron/process_gunbroker_queue_parallel.php , Both processors had two compounding bugs: 1. The generic failure handler bumped attempts but never wrote $e->getMessage() to result_message. So 100k+ daily failures only showed the initial queuing reason ("Catch all: in stock product with no active listing"). The real GB API errors were echoed to stdout only. 2. The SELECT used WHERE status='pending' AND attempts < 3 but the failure handler immediately set status='failed' , making max_attempts=3 a lie. Every row got exactly ONE attempt before being permanently dead.
New includes/gunbroker-queue-helpers.php with tgdQueueFailOrRetry() , persists the real error to result_message (concatenated, doesn't wipe the queuing reason), only marks status='failed' when attempts >= max_attempts, otherwise keeps status='pending' with process_after = NOW() + 15 MINUTE backoff. SELECTs now also honor (process_after IS NULL OR process_after <= NOW()).
Sequential processor now checks $listingData['error'] BEFORE calling createListing() , previously the error array was passed through and createListing complained about missing Title, masking real reasons (MAP guard, blocked SKU, price safeguard, etc.).
Parallel processor now pulls $listingData['message'] instead of the boolean error key (was logging "buildListingFromProduct: true"). Plus:, GB access token refresh every 5 min in the batch loop ($gb->authenticate() once at startup left the token to expire on long runs), HTTP 401 handled separately: force token refresh, mark row pending WITHOUT burning an attempt, HTTP 400 errors now capture userMessage/message/error from response body , full GB API rejection visible, DB insert failure after successful GB create now captures the orphan prevention status

Real Error Distribution Discovered

Verification

catch all eligible count: 3,764 → 23,696 (6.3x)
Active listings expected to climb steadily toward the full eligible set at the parallel processor's ~1,200/hour throughput
All future queue failures now show the real reason in result_message for ongoing diagnostics

Files Changed

cron/sync_gunbroker_parallel.php , stability gate refined
cron/process_gunbroker_queue.php , error check + tgdQueueFailOrRetry
cron/process_gunbroker_queue_parallel.php , token refresh + 401 handler + error message + tgdQueueFailOrRetry
includes/gunbroker-queue-helpers.php , NEW

All releases: What's new in Trinity. The same notes are on the What's New page in your admin.

Still stuck? Email support@2adata.com and tell us which article you were reading.