BUG/MEDIUM: peers: trash of expired entries delayed after fullresync

stksess_new has set the entry expire to the table expire delay,
if it is a new entry, set_entry inserts at that position in the expire
tree. There was a touch_remote updating the expire setting but the
tree's re-ordering is not designed to set back in the past resulting
to an entry that will be trashed only after a full table's expire delay
regardless the expire set on the stktsess.

This patch sets the newts expire before the call of 'set_entry'.
This way a new inserted entry is set directly at the right position
in the tree to trash the entry in time.

This patch should be backported on all supported branches and at
least v2.8
This commit is contained in:
Emeric Brun 2026-04-10 10:33:52 +02:00 committed by Willy Tarreau
parent 90e8ccd9c2
commit 8f06c8fda4

View file

@ -1895,6 +1895,18 @@ int peer_treat_updatemsg(struct appctx *appctx, struct peer *p, int updt, int ex
newts->shard = stktable_get_key_shard(table, newts->key.key, keylen);
/* stksess_new has set the entry expire to the table expire delay,
* if it is a new entry set_entry inserts at that position in the expire
* tree the touch_remote updates this date but the tree's re-order is not
* designed to set back in the past, and the entry will be trashed only
* after a full table's expire delay regardless the setting.
* But setting the expire on newts here allows to set directly new entries
* at the right position and to trash the entry in time if it is a new
* created one from resync process for instance.
*/
newts->expire = tick_add(now_ms, expire);
/* lookup for existing entry */
ts = stktable_set_entry(table, newts);
if (ts != newts) {