Summary
After rebasing a PR onto the latest main, CI started failing in tests/unit/eloq/list.tcl on a blocking list pop case.
The failure does not appear to come from the PR itself. The PR only changes slowlog timestamp handling, but after rebasing onto:
eloqkv/main: 547a0e4c14ebcc82f192917663d1210cb2916c48data_substrate: dc37e861e4b3ffbcc3eb320754c62c889f325126
CI reports a regression in blocked list wake-up behavior.
Failing test
tests/unit/eloq/list.tcl around the "BLPOP: arguments are empty" case:
bpop_command_two_key $rd $pop blist1{t} blist2{t} 1
wait_for_blocked_client
r rpush blist1{t} foo
assert_equal {blist1{t} foo} [$rd read]Actual behavior
The blocked client returns an empty result / timeout instead of being unblocked by the RPUSH.
CI failure excerpt:
*** [err]: BLPOP: arguments are empty in tests//unit/eloq/list.tcl
Expected 'blist1{t} foo' to be equal to ''
This suggests the blocked BLPOP was not woken up after RPUSH blist1{t} foo, and instead timed out.
Why this looks unrelated to the PR
The rebased PR head is 0433ce493b2a2b456d294190f90f16a8b80370ec, and its diff against main only touches:
src/redis_service.cpptests/unit/eloq/slowlog.tcltests/unit/slowlog.tcl
No list / blocking command code is modified in the PR.
Suspected cause
Most likely this was exposed by the updated data_substrate version on main, not by the slowlog change itself.
In particular, recent data_substrate changes include concurrency / waiter handling updates, e.g. the commit history near the pinned submodule version includes:
4621885 fix: avoid bthread mutex deadlock between tx processors and bthread waiters (#491)
That area seems consistent with a regression where blocked commands are not resumed correctly after a write.
Impact
This can cause unrelated PRs rebased onto current main to fail CI on blocking list tests.
Summary
After rebasing a PR onto the latest
main, CI started failing intests/unit/eloq/list.tclon a blocking list pop case.The failure does not appear to come from the PR itself. The PR only changes slowlog timestamp handling, but after rebasing onto:
eloqkv/main:547a0e4c14ebcc82f192917663d1210cb2916c48data_substrate:dc37e861e4b3ffbcc3eb320754c62c889f325126CI reports a regression in blocked list wake-up behavior.
Failing test
tests/unit/eloq/list.tclaround the"BLPOP: arguments are empty"case:Actual behavior
The blocked client returns an empty result / timeout instead of being unblocked by the
RPUSH.CI failure excerpt:
This suggests the blocked
BLPOPwas not woken up afterRPUSH blist1{t} foo, and instead timed out.Why this looks unrelated to the PR
The rebased PR head is
0433ce493b2a2b456d294190f90f16a8b80370ec, and its diff againstmainonly touches:src/redis_service.cpptests/unit/eloq/slowlog.tcltests/unit/slowlog.tclNo list / blocking command code is modified in the PR.
Suspected cause
Most likely this was exposed by the updated
data_substrateversion onmain, not by the slowlog change itself.In particular, recent
data_substratechanges include concurrency / waiter handling updates, e.g. the commit history near the pinned submodule version includes:4621885 fix: avoid bthread mutex deadlock between tx processors and bthread waiters (#491)That area seems consistent with a regression where blocked commands are not resumed correctly after a write.
Impact
This can cause unrelated PRs rebased onto current
mainto fail CI on blocking list tests.