CleanOrphanUploadFiles may skip records when using offset pagination
还没有人认领这个 Issue。
评估
调研方向
Start at the CleanOrphanUploadFiles entry point and trace its batch query and interaction with DeleteAndMoveFileRecord. Verify the cleanup continues scanning all records eligible at the start of the run, including the 1001-record reproduction case, without leaving an eligible record Available.
由索引模型根据 Issue 内容生成。
描述
Describe the bug
CleanOrphanUploadFiles may skip some available file records during a cleanup run because it uses offset-based pagination while modifying the same result set being paginated.
The cleanup job queries file records with status = Available in batches of 1000. While processing a batch, orphan files are cleaned by DeleteAndMoveFileRecord, which changes their status from Available to Deleted.
Because those records no longer match the status = Available condition, the result set becomes smaller. However, the next iteration increments the page number and continues using an offset calculated from the new result set.
For example, if there are 1001 eligible orphan records:
- Page 1 queries the first 1000 records with
OFFSET 0. - Those 1000 records are changed from
AvailabletoDeleted. - Only 1
Availablerecord remains. - Page 2 queries with
OFFSET 1000. - The remaining record is skipped, so the query returns no records and the cleanup loop exits.
As a result, not all eligible orphan file records are guaranteed to be checked in a single cleanup run. The skipped records remain Available and may only be processed by a later cleanup run.
To Reproduce
Steps to reproduce the behavior:
-
Create 1001 file records with:
status = AvailableCreatedAtolder than 2 days- no revision or other object referencing the uploaded file
- corresponding uploaded files present on disk
-
Run
CleanOrphanUploadFiles. -
Query the remaining file records with
status = Available. -
Observe that at least one eligible orphan record remains unprocessed.
The issue comes from combining offset pagination with updates to the filtered result set:
First query:
OFFSET 0 LIMIT 1000
→ 1000 records are processed
→ their status changes from Available to Deleted
Remaining Available records:
1
Second query:
OFFSET 1000 LIMIT 1000
→ returns no records
→ cleanup exits
Expected behavior
CleanOrphanUploadFiles should scan all file records that are eligible for the current cleanup run, even when previously scanned records are changed from Available to Deleted.
No eligible record should be skipped because earlier records were removed from the Available result set during the same cleanup execution.
Screenshots
Not applicable.
Platform
- Device: N/A
- OS: Not OS-specific
- Browser and version: N/A
- Version: current
main(3b9f1370612e690a0b7f230f05e688930db4c6d3) - Deployment method: Source
- 主要语言
- Go
- 星标
- 15.7k
- 派生
- 1.4k
- 平均合并
- 1 天 20 小时
- 30 天内合并 PR
- 6
贡献指南
这个仓库没有索引到贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
apache/answer 的其他 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 65/100
-
Hardening: cap the invite_user list size in UpdateQuestionInviteUser to bound notification fan-out 未关闭
难度 2/5 1-3 小时 新手友好度 72/100
-
难度 2/5 1-3 小时 新手友好度 84/100
-
难度 2/5 1-3 小时 新手友好度 88/100
-
Gravatar hash is computed from the un-lowercased email, so mixed-case accounts render an identicon 未关闭
难度 2/5 1-3 小时 新手友好度 85/100
相似的 Issue
-
bug github_actions
难度 2/5 1-3 小时 新手友好度 75/100
registrystack/registry-stack#1393 ·
-
难度 2/5 1-3 小时 新手友好度 75/100
JakeChampion/lang#10213 ·
-
难度 2/5 1-3 小时 新手友好度 70/100
oasisprotocol/oasis-sdk#2523 ·
-
难度 2/5 1-3 小时 新手友好度 75/100
-
难度 2/5 1-3 小时 新手友好度 70/100