Conversation
e.Client()を毎回呼び出すのではなく、ポインタを格納した変数を用いるように変更 Signed-off-by: Yuito Akatsuki (Tani Yutaka) <yuito@yuito-it.jp>
毎回cronjobでログインするとrate limitに引っかかるので、Webhookを用いるようにする Signed-off-by: Yuito Akatsuki (Tani Yutaka) <yuito@yuito-it.jp>
その他HTTPのリクエストにおいても同様に扱うべきであるため。 Signed-off-by: Yuito Akatsuki (Tani Yutaka) <yuito@yuito-it.jp>
Signed-off-by: Yuito Akatsuki (Tani Yutaka) <yuito@yuito-it.jp>
RSSの更新をWebhookで行うことによってレートリミットの制限を受けないようにする。 Signed-off-by: Yuito Akatsuki (Tani Yutaka) <yuito@yuito-it.jp>
Signed-off-by: Yuito Akatsuki (Tani Yutaka) <yuito@yuito-it.jp>
レートリミットを考慮 Signed-off-by: Yuito Akatsuki (Tani Yutaka) <yuito@yuito-it.jp>
Signed-off-by: Yuito Akatsuki (Tani Yutaka) <yuito@yuito-it.jp>
|
Warning Review limit reached
More reviews will be available in 51 minutes and 12 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 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 |
There was a problem hiding this comment.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
src/cmd/rss_cron/main.go (1)
110-119:⚠️ Potential issue | 🟠 Major | ⚡ Quick win送信に失敗したら最新hashを進めないでください。
CreateContentがrate limitやWebhook削除で失敗しても、Line 117-119 で最新記事を既読扱いにするため、未送信の記事が次回以降も通知されません。少なくとも送信失敗時はIsFailedを立ててcontinueし、成功扱いのhash更新を避けてください。修正例
+ sendFailed := false for _, item := range targetItems { itemTitle := item.Title if itemTitle == "" { itemTitle = "(タイトルなし)" @@ _, err := client.CreateContent(message) if err != nil { log.Print("Message create error:", err) + sendFailed = true + break } } + if sendFailed { + rssSetting.IsFailed = true + if err := repo.Update(rssSetting); err != nil { + log.Print("Update Record Failed", err) + } + continue + } // 送信完了後に最新ハッシュを保存(feed.Items[0] = 最新記事) newestHash := base64.StdEncoding.EncodeToString([]byte(fmt.Sprintf("%s:%s", feed.Items[0].Title, feed.Items[0].Description)))🤖 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 `@src/cmd/rss_cron/main.go` around lines 110 - 119, When the client.CreateContent(message) call returns an error, do not proceed with updating the newestHash and setting IsFailed to false. Instead, set rssSetting.IsFailed to true and use continue to skip to the next iteration of the loop, ensuring that failed message sends do not mark articles as processed. Only update the newestHash and set IsFailed to false when CreateContent succeeds without error.src/internal/bot/handlers/interaction/command/general/rss/subscribe.go (1)
145-164:⚠️ Potential issue | 🟠 MajorWebhook作成失敗時の補償削除を追加してください。
CreateWebhook(145行目) で正常に作成されたWebhookは、後続のGetOrCreate(152行目) またはrssRepo.Create(156-163行目) が失敗した場合、DBには登録されないままDiscord上に残ります。これにより、チャンネルのWebhook上限消費やセキュリティリスク(不要な送信可能URL残存)につながります。DB保存失敗時に
client.Rest.DeleteWebhook()を使用した補償削除を実装してください。🤖 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 `@src/internal/bot/handlers/interaction/command/general/rss/subscribe.go` around lines 145 - 164, The webhook created successfully via CreateWebhook will remain on Discord if subsequent database operations fail. Add compensating deletion logic by wrapping the GetOrCreate and rssRepo.Create calls in error handling that calls client.Rest.DeleteWebhook() with the webhook ID when either operation fails. This ensures that if GetOrCreate or rssRepo.Create returns an error, the webhook is deleted from Discord before returning the error, preventing orphaned webhooks that consume channel limits and pose security risks.
🤖 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 `@argoCD/base/cronjob.yaml`:
- Line 6: The schedule field in the cronjob.yaml file is using a 7-field Quartz
cron format, but Kubernetes CronJob's .spec.schedule field only supports the
standard 5-field cron format (minute, hour, day, month, day-of-week). Replace
the current schedule value with the correct 5-field format to ensure the API
server accepts the resource and the job executes properly every 10 minutes.
In `@src/cmd/rss_cron/main.go`:
- Around line 85-88: In the webhook initialization block where
webhook.NewWithURL is called, change the argument from rssSetting.URL to
rssSetting.WebhookURL to use the correct webhook destination URL instead of the
RSS feed URL. Additionally, when the webhook client creation fails, do not
simply log the error and continue; instead, implement proper error state
handling similar to the feed retrieval error handling pattern used elsewhere (by
setting a failure flag and updating the subscription state before proceeding to
the next subscription), ensuring that an invalid webhook client does not proceed
to the sending loop.
In `@src/internal/bot/handlers/interaction/command/general/rss/subscribe.go`:
- Around line 110-130: Add a nil guard to check if feed.Image is not nil before
accessing feed.Image.URL in the feedImageURL assignment. Additionally, when
reading the response body with io.ReadAll in the HttpGet result handler, wrap
resp.Body with io.LimitReader to enforce a maximum size limit to prevent memory
exhaustion. Finally, ensure the response body from util.HttpGet is properly
closed by deferring resp.Body.Close() immediately after the error check to
prevent resource leaks, or use defer before the error handling.
In `@src/internal/model/rss_setting.go`:
- Line 7: The WebhookURL field in the RssSetting struct is being set with a not
null constraint, which will fail for existing database rows during schema
migration. Implement a phased migration strategy: first add the WebhookURL
column as nullable (remove the "not null" tag from the struct definition), then
create a separate data migration that populates WebhookURL values for all
existing RSS settings (such as generating default webhook URLs or retrieving
them from a source), and finally in a subsequent migration make the column not
null by re-applying the struct tag. This ensures existing data is properly
backfilled before the NOT NULL constraint is enforced.
In `@src/internal/util/http.go`:
- Around line 72-77: The `HttpGet` function currently closes the response body
with `defer resp.Body.Close()` before returning it, which means callers receive
an already-closed body that cannot be read. This causes failures in FetchFeed
when attempting to parse the body and in image fetching operations. Remove the
`defer resp.Body.Close()` statement so that on success, the responsibility to
close the body is transferred to the caller, but ensure the response body is
explicitly closed in the error handling path when the status code is not
http.StatusOK before returning the error.
---
Outside diff comments:
In `@src/cmd/rss_cron/main.go`:
- Around line 110-119: When the client.CreateContent(message) call returns an
error, do not proceed with updating the newestHash and setting IsFailed to
false. Instead, set rssSetting.IsFailed to true and use continue to skip to the
next iteration of the loop, ensuring that failed message sends do not mark
articles as processed. Only update the newestHash and set IsFailed to false when
CreateContent succeeds without error.
In `@src/internal/bot/handlers/interaction/command/general/rss/subscribe.go`:
- Around line 145-164: The webhook created successfully via CreateWebhook will
remain on Discord if subsequent database operations fail. Add compensating
deletion logic by wrapping the GetOrCreate and rssRepo.Create calls in error
handling that calls client.Rest.DeleteWebhook() with the webhook ID when either
operation fails. This ensures that if GetOrCreate or rssRepo.Create returns an
error, the webhook is deleted from Discord before returning the error,
preventing orphaned webhooks that consume channel limits and pose security
risks.
🪄 Autofix (Beta)
✅ Autofix completed
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: e78440e6-344b-45a9-9670-3c440a20e5dc
📒 Files selected for processing (7)
argoCD/base/cronjob.yamlargoCD/overlays/sub/env.yamlsrc/cmd/rss_cron/main.gosrc/internal/bot/handlers/interaction/command/general/rss/subscribe.gosrc/internal/model/rss_setting.gosrc/internal/util/http.gosrc/internal/util/rss_fetch.go
|
Note Autofix is a beta feature. Expect some limitations and changes as we gather feedback and continue to improve it. Fixes Applied SuccessfullyFixed 5 file(s) based on 5 unresolved review comments. Files modified:
Commit: The changes have been pushed to the Time taken: |
Fixed 5 file(s) based on 5 unresolved review comments. Co-authored-by: CodeRabbit <noreply@coderabbit.ai>
Signed-off-by: Yuito Akatsuki (Tani Yutaka) <yuito@yuito-it.jp>
Signed-off-by: Yuito Akatsuki (Tani Yutaka) <yuito@yuito-it.jp>
|
Caution Failed to replace (edit) comment. This is likely due to insufficient permissions or the comment being deleted. Error details |
✅ Action performedReview finished.
|
Summary by CodeRabbit
リリース ノート