What happened?
The in-memory repositories are the reference backends for RuntimeBrokerService tests, but their semantics drift from the JDBC ones, so those tests are blind to JDBC-only behavior:
Split out from #13183 (medium cluster).
What did you expect to happen?
Either align the in-memory implementations with the JDBC semantics (including the 100-row pass bound and lease rounding), or run the shared repository contract suite (RuntimeRecoveryContract) against both backends with the drift points pinned explicitly, so a divergence fails the build.
Client information
N/A — code audit finding.
中文
发生了什么？
InMemory 仓库是 RuntimeBrokerService 服务层测试的参考后端，但其语义与 JDBC 实现漂移，导致这些测试对 JDBC 专有行为失明：
拆自 #13183 的 Medium 簇。
期望行为
二选一：让 InMemory 实现对齐 JDBC 语义（含 100 行批次上界与租约取整），或让共享仓库契约套件（RuntimeRecoveryContract）同时跑两种后端并显式钉住漂移点，使漂移在构建期失败。
客户端信息
N/A —— 代码审计发现。
What happened?
The in-memory repositories are the reference backends for
RuntimeBrokerServicetests, but their semantics drift from the JDBC ones, so those tests are blind to JDBC-only behavior:InMemoryRuntimeBindingRepository.renewOperationusesnow.plus(duration)with none of JDBC's whole-secondleaseUntilrounding (JdbcRepositorySupport.leaseUntil).recoverLost/finishLostRecoveryrelease all sessions in one pass; JDBC batches withLIMIT 100 FOR UPDATE(the fix(runtime-broker): cross-process admit/release race, shared single-thread renewals, single-token HTTP #13183 reclaim fix loops the bounded passes at the service layer precisely because of this).completeSessionReleaseatomicity differ in details.Split out from #13183 (medium cluster).
What did you expect to happen?
Either align the in-memory implementations with the JDBC semantics (including the 100-row pass bound and lease rounding), or run the shared repository contract suite (
RuntimeRecoveryContract) against both backends with the drift points pinned explicitly, so a divergence fails the build.Client information
N/A — code audit finding.
中文
发生了什么？
InMemory 仓库是
RuntimeBrokerService服务层测试的参考后端，但其语义与 JDBC 实现漂移，导致这些测试对 JDBC 专有行为失明：InMemoryRuntimeBindingRepository.renewOperation用now.plus(duration)，没有 JDBC 的整秒leaseUntil取整(JdbcRepositorySupport.leaseUntil)。recoverLost/finishLostRecovery一趟释放全部 session;JDBC 用LIMIT 100 FOR UPDATE分批(fix(runtime-broker): cross-process admit/release race, shared single-thread renewals, single-token HTTP #13183 的 reclaim 修复之所以在服务层循环这些有界批次，原因正在于此)。completeSessionRelease原子性也有细节差异。拆自 #13183 的 Medium 簇。
期望行为
二选一：让 InMemory 实现对齐 JDBC 语义（含 100 行批次上界与租约取整），或让共享仓库契约套件（
RuntimeRecoveryContract）同时跑两种后端并显式钉住漂移点，使漂移在构建期失败。客户端信息
N/A —— 代码审计发现。