The last merge lands the item

A route is the item broken into nodes, each its own PR. Every node's PR carries a few lines at the bottom of its description: SLEDS-Source: says which item the work belongs to, SLEDS-Node: says which node it is. When the PR merges, SLEDS reads those lines and lands the node. When the last node lands, the item lands with it, comes off the sled, and whatever was waiting on it is ready to start.

That last step could fail quietly. If the Source line named a source another item also used, or left out the item part of the source, SLEDS looked for the node on the wrong item, did not find it, and stopped there. The node never landed, so neither did the item. It sat on the sled as though work were still going on, and every item blocked behind it stayed blocked until someone recorded the actual by hand.

What happens now

The last node's merge lands the item, whoever holds it: a person who ran the node themselves, or an engine run that opened the PR overnight. When the Source line does not point straight at the item, SLEDS looks at the live items filed under the same doc and picks the one whose route has that node. The item lands, leaves the sled, and the items blocked by it go ready, as the route always promised.

It never guesses. If two items under that doc both have the node still open, SLEDS lands neither and leaves it for a person, rather than closing the wrong one.

Why it matters

A route is a promise that the work moves on its own once each piece merges. An item stuck after its last merge breaks that twice: the sled shows work that is finished, and the next items wait on a step nobody knows is owed. Engineers on routes saw it as an item that would not let go. Now the merge is the whole signal, and nothing has to be closed by hand.

The cases are covered in the route's landing tests (SL-2077 — the last node landing from the PR line lands the item): a person or an engine holding the item, with its own source, a source another item shares, or a Source line without the item.