fix: data loss in asyncsearch merge caused by concurrent retention deletion of fracs

[eguguchkin]

• I have read and followed all requirements in CONTRIBUTING.md;
• I used LLM/AI assistance to make this pull request;

[github-actions]

❌ PR Title Validation Failed
Please refer to CONTRIBUTING.md

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 70.74%. Comparing base (25381c2) to head (4cf18dd).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #459      +/-   ##
==========================================
+ Coverage   70.51%   70.74%   +0.22%     
==========================================
  Files         232      232              
  Lines       18268    18271       +3     
==========================================
+ Hits        12881    12925      +44     
+ Misses       4426     4389      -37     
+ Partials      961      957       -4     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

🔴 Performance Degradation

Some benchmarks have degraded compared to the previous run.
Click on Show table button to see full list of degraded benchmarks.

Show table

Name	Previous	Current	Ratio	Verdict
MutexListAppend-4	25381c	9d4289
	199.21 MB/s	175.59 MB/s	0.88	🔴
	80797744.00 ns/op	91119098.00 ns/op	1.13	🔴

[dkharms]

Wait, but we are reading the .qpr file here which has different lifetime and does not depend on fraction's lifetime. Am I missing something?

Or you mean retention of asyncsearcher (like how long asynchronous request can survive)?

[eguguchkin]

Issue: when a user starts an async search with from close to the last fraction, the search may take hours. By the time it reaches that fraction, it might already be gone due to rotation. We currently ignore this as a valid case (

seq-db/asyncsearcher/async_searcher.go

Line 403 in 59fdb2b

if !ok { // oldest fracs may already be removed

). However, when we later merge all remaining fractions, a missing fraction's qpr fails the ENTIRE merge.

[eguguchkin]

Anyway, the async search queue will be reworked to use intervals soon, but for now we see this error a few times a week in logs. Users don't notice the missing data, but we should fix it sooner rather than later.