Carousel Partial-Retry URL Mapping Automation: The Slide That Remembered the Wrong Picture

A partial retry of a multi-step batch operation — publish everything that has not already been published — is a reasonable, common design: it lets a failed or interrupted batch pick up cleanly without redoing completed work. It also, almost unavoidably, produces two lists of different lengths describing the same underlying batch: the full, original list of everything the batch was ever meant to do, and the shorter list of what is actually happening in THIS specific call, with already-done items filtered out. Using a position number that is only meaningful within one of those two lists to index into the OTHER one is a natural, easy mistake — both lists hold the same kind of item, in a related order, and the code compiles and runs without any visible error either way. The mismatch only produces a wrong result, silently, specifically when the two lists' lengths actually differ — which is precisely the case a partial retry exists to handle.

Centriu Atlas can publish a multi-image carousel post to a connected social network, and records, for each slide of that carousel, which specific external post ID corresponds to which specific image URL — a mapping later used both for basic bookkeeping (what was actually published) and, critically, as the input to an idempotency check on any FUTURE retry of the same content item: the system recognizes a slide as already-published specifically by matching its recorded URL.

A retry of a carousel that had already partially succeeded is a genuinely common path: some slides published cleanly in an earlier call are correctly identified and skipped (tracked via `skipUrls`/`alreadyPubUrls`), and only the remaining, still-needed slides are actually published in the retry. The code recording the URL for each newly published slide, before this fix, worked out that URL as follows: find the position of the current post's external ID WITHIN `postIdsToRecord` — the short list of post IDs created in THIS specific call — and use that position as an index into `effectiveCarousel`, the FULL, original list of every slide's URL for the entire carousel, in its original order.

On a complete, first-attempt publish — no earlier slides skipped, every slide published in one call — `postIdsToRecord` and `effectiveCarousel` happen to have the same length and the same order, so this indexing produces the correct answer by coincidence, and the defect is completely invisible. On a genuine partial retry, the two lists diverge: if the first slide of a three-slide carousel was already published in an earlier call and only slides two and three are being published now, `postIdsToRecord` contains exactly two entries, at positions 0 and 1 — but `effectiveCarousel[0]` is actually slide ONE's url (the global, original list), and `effectiveCarousel[1]` is slide TWO's url. The post actually corresponding to slide two would be recorded with slide one's URL, and the post for slide three would be recorded with slide two's URL — every slide in the retry mapped to the URL belonging exactly one position earlier than its own real image, with the drift growing by one for every earlier slide that had been skipped.

Because the recorded URL is the exact field a later retry's own idempotency logic reads to recognize "this slide is already done," a wrong mapping does not stay a harmless bookkeeping inaccuracy — it can propagate: a future retry checking whether a specific slide's URL already has a recorded post could match against the WRONG post, incorrectly treating an unpublished slide as done (skipping it) or an already-published slide as not done (re-publishing it), compounding across however many retries a given carousel needed.

The fix separates the two lists cleanly. A new `urlsForRecord` array is built specifically from `stillNeededUrls` — the URLs for only the slides actually being published in this specific call, already known to be in the same order the publisher iterated them — rather than the full, original carousel list. The insertion loop is rewritten to iterate `postIdsToRecord` by explicit numeric position (`for (let i = 0; i < postIdsToRecord.length; i++)`), and looks up each post's URL as `urlsForRecord[i]` — the i-th URL still needed in THIS call, matched against the i-th post ID created in THIS call, with no dependency on the full original list's own length or ordering at all.

Before the fix, a three-image carousel where the first slide published successfully in an earlier call, with slides two and three published in a retry, would record slide two's actual post against slide one's URL, and slide three's actual post against slide two's URL — a complete carousel, correctly published end to end, but with its own internal bookkeeping now describing the wrong picture for two of its three slides. After the fix, the retry correctly matches each newly published post to its own actual URL, regardless of how many earlier slides the retry itself had to skip.

Centriu Atlas now records an accurate post-to-URL mapping for every slide of a carousel published across a partial retry, closing a gap where the mapping could silently drift by one position for every earlier slide the retry skipped — a drift that could otherwise compound into an incorrect skip or an incorrect re-publish on a SUBSEQUENT retry of the same content item, since the idempotency check that later retry relies on reads exactly this recorded field.

This automation governs Centriu Atlas's own internal bookkeeping for which URL corresponds to which published carousel slide, specifically during a partial retry — it does not change how or when a carousel is retried, and single-image posts (which never used this specific indexed lookup) were unaffected by the defect this fix corrects.

Reusing a loop position from a shorter, filtered list to index into a longer, unfiltered one is the more compact way to write the lookup, and it is entirely correct as long as the two lists always happen to be the same length — true for a complete, first-attempt publish, but not true for a genuine partial retry. Building a dedicated list scoped to exactly what the current call is actually doing, and indexing only within that list, costs one extra array but removes the dependency on the two lists ever needing to match in length at all — closing the gap for every retry scenario, not only the ones a specific test happened to exercise.