Linked lists and node identity

A pending-job queue stores linked nodes, and other parts of the app hold references to particular jobs. A customer category is disabled, so all matching jobs must leave the queue. Rebuilding a fresh chain with the same surviving values would leave those references pointing at the old objects.

This is why node identity matters. The task is to reconnect the existing survivors, including when cancelled jobs appear consecutively or at the head.

Removing cancelled jobs without replacing survivors

Linked-list identity makes the problem stronger than returning equal values. A pointer names an existing node; copying its fields creates a different object. Removing a node changes a predecessor link rather than shifting later values.

Reconnecting through the predecessor

In 2 → 5 → 5 → 7, removing category 5 means keeping the predecessor at 2 while bypassing both matching nodes. Advancing after the first removal would skip the second. A temporary sentinel before the head gives a head removal the same predecessor-based operation as every other removal. Return its next link, not the sentinel itself.

tail := &Node{Value: 3}
head := &Node{Value: 1, Next: tail}
fmt.Println(head.Next == tail) // pointer identity

What the links do not make cheap

Head removal has no ordinary predecessor, so a sentinel can unify cases. Advance the predecessor only when retaining its next node; otherwise consecutive removals get skipped. This matters in intrusive queues and identity-sensitive indexes. A slice is often simpler when node identity is irrelevant.

For n nodes and b blocked values, building a hash set and scanning the chain takes expected O(n+b) time with O(b) set storage. Link editing itself needs constant pointer state. A value-to-node wrapper or a fresh copied list has its own allocation cost and cannot replace a node-identity requirement.

Other components can keep their references to surviving jobs because those nodes were never replaced.