When the system prunes community events, why doesn't it prune the oldest? [duplicate]

Question

We use community events to promote new blog posts. Because we've had a lot of activity lately (yay!), we're sometimes showing three events at a time. (I run each event for around a week, so there's usually a little overlap with the oldest post when we post a new one.) Because the URLs need to be different, I'm using the full URL for the question for the newest one, and the answer link with and without my user ID for the other two. That's been working fine (the per-user share link actually counts as different).

On main, one of our events is being bumped by an SE-wide announcement. That's expected behavior, but what's not expected is which one got bumped. Here's what we see on main:

And here's what we see on meta, with the missing one circled:

Why, on main, did the system omit the one in the middle chronologically? I would have expected the oldest one to drop off. Shouldn't newer events have priority? (I realize that "oldest" and "expiring soonest" aren't the same thing, and working out the correct behavior means figuring out which we mean. On this site, they are usually the same -- we don't queue up events well in advance or run a bunch of newer, shorter ones.)

It's not about recency of editing, either. When I post a new event I first edit the previously-newest one to change its URL, and then post the new one with the question URL (that the previous one had until my edit). So the newest two events are also the most-recently-edited two events.

Answer 1

This is actually the same bug as your other one: the system does not differentiate between short URLs with a user ID attached and short URLs without one (or long URLs that point to the same post, for that matter). So when the merge logic runs, you'll get the first item that matches a given answer or question and the rest will be dropped.

The merge logic only runs when MSE-featured posts are added though. And they don't run on meta.

The fix that Michael proposed on the other bug report would thus fix this one as well.

In the meantime... If you want to get away from creating more questions or answers while still thwarting the merge logic, you're gonna have to break the parsing somehow while still allowing the URL to actually work. Try adding extra slashes (/q/////5713) or selectively URL-encoding parts of the ID (/q/%35713). If you manage to stop the parser from recognizing it as a post link completely, then you can use the same URL in every event - the system will fall back on the title to distinguish between them.