CleanOrphanUploadFiles may skip records when using offset pagination
まだ誰も着手していません。
評価
調査の方向性
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時間
- マージ済み PR(30日)
- 6
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- 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