fix: resolve memory crash on large image imports by adding thumbnails and bounded concurrency#109
Merged
Merged
Conversation
… and bounded concurrency
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughSummary by CodeRabbitリリースノート
Walkthroughフィルムストリップで高解像度画像を直接読み込むことによるメモリクラッシュを解消するため、Go バックエンドに ChangesサムネイルAPI追加とメモリクラッシュ対策
Sequence Diagram(s)sequenceDiagram
rect rgba(173, 216, 230, 0.5)
note over Frontend,app.go: 画像インポートフロー
Frontend->>app.go: ProcessPaths (ファイルパス群)
app.go->>app.go: 有効パス > 2000 件 → 先頭2000件に切り詰め + エラーExifResult追加
app.go->>handler.go: registerImageToken (imageToken, thumbToken)
app.go-->>Frontend: ExifResult { imageURL, thumbURL }
end
rect rgba(144, 238, 144, 0.5)
note over Frontend,handler.go: サムネイル表示フロー
Frontend->>handler.go: GET /api/thumb?token=xxx
handler.go->>handler.go: fileOpenSem 取得
handler.go->>handler.go: EXIF JpegThumbnail 試行
alt EXIF サムネイルあり
handler.go-->>Frontend: image/jpeg (EXIF 埋め込みサムネイル)
else EXIF なし / サイズ不足
handler.go->>handler.go: thumbProcessSem 取得 → デコード → 256px リサイズ
handler.go-->>Frontend: image/jpeg (リサイズ済みサムネイル)
end
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50分 Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@app.go`:
- Around line 214-218: The hardcoded limit value of 2000 in the validPaths
length check is not unified with the maxImageTokens constant defined elsewhere,
leading to duplicate management of the same threshold. Extract the 2000 value
into a single shared constant definition that can be referenced in both the
len(validPaths) comparison and the maxImageTokens definition. This ensures the
image import limit and token holding limit remain synchronized and prevents
future misalignment when either limit needs to be updated.
In `@handler.go`:
- Around line 160-163: The error return values from w.Write(pic) and
jpeg.Encode(...) calls in the image response handler are not being checked,
making it impossible to detect connection failures or write errors. Check the
error return value from both w.Write(pic) and the jpeg.Encode(...) call wherever
they appear in handler.go (including the instances around line 160 and line
202), and handle any errors appropriately by logging them or writing an error
response to the client. Do not silently ignore these errors as they make it
difficult to diagnose failures in production.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: df38719a-70c8-4425-ba8b-80bbfb0eee59
📒 Files selected for processing (5)
app.gofrontend/src/App.tsxfrontend/src/hooks/useImageManager.tsfrontend/src/types.tshandler.go
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@handler.go`:
- Line 221: The w.Write(buf.Bytes()) call on line 221 does not check or log
errors from the write operation, whereas similar error handling is performed for
EXIF thumbnail writes in the earlier section (lines 162-164). Although HTTP
errors cannot be returned after headers are already sent, you should capture the
error returned by w.Write and add logging to record any write failures for
debugging purposes, following the same pattern used in the EXIF thumbnail error
handling.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 272c316d-1f75-4ec5-a935-57fa65aaac3d
📒 Files selected for processing (2)
app.gohandler.go
| } | ||
|
|
||
| w.Header().Set("Content-Type", "image/jpeg") | ||
| w.Write(buf.Bytes()) |
Contributor
There was a problem hiding this comment.
w.Write のエラーを検査してログ出力してください。
Line 162-164 では EXIF サムネイル書き込み時にエラーをログ出力していますが、こちらでは未処理です。ヘッダー送信後なので HTTP エラーは返せませんが、デバッグのためにログ出力を追加してください。
🔧 修正案
w.Header().Set("Content-Type", "image/jpeg")
- w.Write(buf.Bytes())
+ if _, err := w.Write(buf.Bytes()); err != nil {
+ log.Printf("Failed to write generated thumbnail: %v", err)
+ }
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| w.Write(buf.Bytes()) | |
| w.Header().Set("Content-Type", "image/jpeg") | |
| if _, err := w.Write(buf.Bytes()); err != nil { | |
| log.Printf("Failed to write generated thumbnail: %v", err) | |
| } | |
| } |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@handler.go` at line 221, The w.Write(buf.Bytes()) call on line 221 does not
check or log errors from the write operation, whereas similar error handling is
performed for EXIF thumbnail writes in the earlier section (lines 162-164).
Although HTTP errors cannot be returned after headers are already sent, you
should capture the error returned by w.Write and add logging to record any write
failures for debugging purposes, following the same pattern used in the EXIF
thumbnail error handling.
Owner
Author
|
@coderabbitai review |
Contributor
✅ Action performedReview finished.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
resolved #108