feat: add channel-level rate limiting - #5067
Draft
zhibisora wants to merge 2 commits into
Draft
Conversation
Contributor
WalkthroughThis PR adds configurable per-channel request rate limiting with Redis or in-memory token buckets, supports channel and key scopes, excludes limited channels or keys during retries, integrates checks into relay and Midjourney flows, and adds configuration UI, localization, documentation, and tests. ChangesChannel Rate Limiting Feature
Estimated code review effort: 4 (Complex) | ~60 minutes Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
⚔️ Resolve merge conflicts
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
🧹 Nitpick comments (2)
model/channel_key_test.go (1)
53-53: ⚡ Quick winUse a GORM delete instead of raw SQL.
Line 53 uses direct SQL even though this can be expressed with GORM and kept fully DB-agnostic in tests.
Proposed change
- require.NoError(t, DB.Exec("DELETE FROM abilities").Error) + require.NoError(t, DB.Where("1 = 1").Delete(&Ability{}).Error)As per coding guidelines, "Prefer GORM methods (
Create,Find,Where,Updates, etc.) over raw SQL queries."🤖 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 `@model/channel_key_test.go` at line 53, Replace the raw SQL deletion with a GORM delete call: instead of DB.Exec("DELETE FROM abilities").Error, call GORM's Delete on the Ability model via the shared DB (e.g., DB.Session(&gorm.Session{AllowGlobalUpdate: true}).Delete(&Ability{}) or DB.Where(...).Delete(&Ability{})) so the test remains DB-agnostic; update the test to use the DB variable and the Ability struct name accordingly.middleware/channel-rate-limit.go (1)
159-162: 💤 Low valueUse
fmt.Errorfinstead oferrors.New(fmt.Sprintf(...)).This is the idiomatic Go pattern for creating formatted errors.
♻️ Suggested fix
func newChannelRateLimitError(channelID int, err error, statusCode int) *types.NewAPIError { if err == nil { - err = errors.New(fmt.Sprintf("channel #%d rate limit reached", channelID)) + err = fmt.Errorf("channel #%d rate limit reached", channelID) }🤖 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 `@middleware/channel-rate-limit.go` around lines 159 - 162, In newChannelRateLimitError, replace the non-idiomatic errors.New(fmt.Sprintf(...)) with fmt.Errorf to create the formatted error (e.g., fmt.Errorf("channel #%d rate limit reached", channelID)); ensure the fmt package is imported if not already and keep the same behavior of assigning the constructed error to err when err == nil.
🤖 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 `@web/classic/src/components/table/channels/modals/EditChannelModal.jsx`:
- Around line 1870-1881: When persisting rate-limit settings in
EditChannelModal.jsx, enforce minimums when
localInputs.channel_rate_limit_enabled is true: ensure
settings.channel_rate_limit_count = Math.max(1,
integerOrDefault(localInputs.channel_rate_limit_count, 0)) and
settings.channel_rate_limit_period_seconds = Math.max(1,
integerOrDefault(localInputs.channel_rate_limit_period_seconds, 60)));
alternatively perform validation on submit and block/save with an error if
localInputs.channel_rate_limit_enabled && (count < 1 || period_seconds < 1).
Update the assignments that set settings.channel_rate_limit_count and
settings.channel_rate_limit_period_seconds (and any related UI validation for
channel_rate_limit_count / channel_rate_limit_period_seconds) to enforce/count
>=1 and period_seconds >=1 when channel_rate_limit_enabled is true.
In `@web/default/src/features/channels/lib/channel-form.ts`:
- Around line 239-248: transformChannelToFormDefaults currently assigns
channelRateLimitCount and channelRateLimitPeriodSeconds from parsed values but
doesn't enforce the schema lower bounds, which can create an invalid form state;
update the assignment for channelRateLimitCount, channelRateLimitPeriodSeconds
(and channelRateLimitScope if relevant) to clamp values so channelRateLimitCount
>= 0 and channelRateLimitPeriodSeconds >= 1 (and if your schema has upper
bounds, also clamp to those maxima) before returning the defaults.
---
Nitpick comments:
In `@middleware/channel-rate-limit.go`:
- Around line 159-162: In newChannelRateLimitError, replace the non-idiomatic
errors.New(fmt.Sprintf(...)) with fmt.Errorf to create the formatted error
(e.g., fmt.Errorf("channel #%d rate limit reached", channelID)); ensure the fmt
package is imported if not already and keep the same behavior of assigning the
constructed error to err when err == nil.
In `@model/channel_key_test.go`:
- Line 53: Replace the raw SQL deletion with a GORM delete call: instead of
DB.Exec("DELETE FROM abilities").Error, call GORM's Delete on the Ability model
via the shared DB (e.g., DB.Session(&gorm.Session{AllowGlobalUpdate:
true}).Delete(&Ability{}) or DB.Where(...).Delete(&Ability{})) so the test
remains DB-agnostic; update the test to use the DB variable and the Ability
struct name accordingly.
🪄 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: CHILL
Plan: Pro
Run ID: afbe5495-49f1-4aa8-a84d-ed263686d904
📒 Files selected for processing (31)
common/limiter/limiter.gocommon/limiter/lua/rate_limit.luacontroller/channel.gocontroller/channel_rate_limit_retry_test.gocontroller/relay.godto/channel_settings.gomiddleware/channel-rate-limit.gomiddleware/channel_rate_limit_test.gomiddleware/distributor.gomodel/ability.gomodel/channel.gomodel/channel_cache.gomodel/channel_key_test.gorelay/mjproxy_handler.gorelay/relay_task.gorelay/relay_task_test.goservice/channel.goservice/channel_select.goservice/error_test.gotypes/error.goweb/classic/src/components/table/channels/modals/EditChannelModal.jsxweb/classic/src/i18n/locales/en.jsonweb/classic/src/i18n/locales/fr.jsonweb/classic/src/i18n/locales/ja.jsonweb/classic/src/i18n/locales/ru.jsonweb/classic/src/i18n/locales/vi.jsonweb/classic/src/i18n/locales/zh-CN.jsonweb/classic/src/i18n/locales/zh-TW.jsonweb/default/src/features/channels/components/drawers/channel-mutate-drawer.tsxweb/default/src/features/channels/lib/channel-form.tsweb/default/src/features/channels/types.ts
Comment on lines
+1870
to
+1881
| settings.channel_rate_limit_enabled = | ||
| localInputs.channel_rate_limit_enabled === true; | ||
| settings.channel_rate_limit_count = integerOrDefault( | ||
| localInputs.channel_rate_limit_count, | ||
| 0, | ||
| ); | ||
| settings.channel_rate_limit_period_seconds = integerOrDefault( | ||
| localInputs.channel_rate_limit_period_seconds, | ||
| 60, | ||
| ); | ||
| settings.channel_rate_limit_scope = | ||
| localInputs.channel_rate_limit_scope === 'key' ? 'key' : 'channel'; |
Contributor
There was a problem hiding this comment.
Validate enabled rate-limit values before persisting.
With the current defaults, enabling rate limit can still submit channel_rate_limit_count = 0 (Line 2569 uses min={0}), which can effectively hard-throttle the channel immediately. Please enforce count >= 1 and period_seconds >= 1 when channel_rate_limit_enabled is true.
Suggested fix
@@
- settings.channel_rate_limit_enabled =
- localInputs.channel_rate_limit_enabled === true;
- settings.channel_rate_limit_count = integerOrDefault(
- localInputs.channel_rate_limit_count,
- 0,
- );
- settings.channel_rate_limit_period_seconds = integerOrDefault(
- localInputs.channel_rate_limit_period_seconds,
- 60,
- );
+ settings.channel_rate_limit_enabled =
+ localInputs.channel_rate_limit_enabled === true;
+ const channelRateLimitCount = integerOrDefault(
+ localInputs.channel_rate_limit_count,
+ 0,
+ );
+ const channelRateLimitPeriodSeconds = integerOrDefault(
+ localInputs.channel_rate_limit_period_seconds,
+ 60,
+ );
+ if (settings.channel_rate_limit_enabled && channelRateLimitCount < 1) {
+ showInfo(t('启用渠道限流时，每周期请求数必须大于 0'));
+ return;
+ }
+ if (
+ settings.channel_rate_limit_enabled &&
+ channelRateLimitPeriodSeconds < 1
+ ) {
+ showInfo(t('启用渠道限流时，周期秒数必须大于 0'));
+ return;
+ }
+ settings.channel_rate_limit_count = channelRateLimitCount;
+ settings.channel_rate_limit_period_seconds =
+ channelRateLimitPeriodSeconds;
@@
- min={0}
+ min={1}Also applies to: 2566-2595
🤖 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 `@web/classic/src/components/table/channels/modals/EditChannelModal.jsx` around
lines 1870 - 1881, When persisting rate-limit settings in EditChannelModal.jsx,
enforce minimums when localInputs.channel_rate_limit_enabled is true: ensure
settings.channel_rate_limit_count = Math.max(1,
integerOrDefault(localInputs.channel_rate_limit_count, 0)) and
settings.channel_rate_limit_period_seconds = Math.max(1,
integerOrDefault(localInputs.channel_rate_limit_period_seconds, 60)));
alternatively perform validation on submit and block/save with an error if
localInputs.channel_rate_limit_enabled && (count < 1 || period_seconds < 1).
Update the assignments that set settings.channel_rate_limit_count and
settings.channel_rate_limit_period_seconds (and any related UI validation for
channel_rate_limit_count / channel_rate_limit_period_seconds) to enforce/count
>=1 and period_seconds >=1 when channel_rate_limit_enabled is true.
Comment on lines
+239
to
+248
| channelRateLimitCount = integerOrDefault( | ||
| parsed.channel_rate_limit_count, | ||
| 0 | ||
| ) | ||
| channelRateLimitPeriodSeconds = integerOrDefault( | ||
| parsed.channel_rate_limit_period_seconds, | ||
| 60 | ||
| ) | ||
| channelRateLimitScope = | ||
| parsed.channel_rate_limit_scope === 'key' ? 'key' : 'channel' |
Contributor
There was a problem hiding this comment.
Clamp parsed rate-limit values to schema bounds.
transformChannelToFormDefaults truncates persisted values but does not enforce count >= 0 and period_seconds >= 1. Bad existing settings can initialize an invalid form state and block submission.
💡 Proposed fix
- channelRateLimitCount = integerOrDefault(
- parsed.channel_rate_limit_count,
- 0
- )
- channelRateLimitPeriodSeconds = integerOrDefault(
- parsed.channel_rate_limit_period_seconds,
- 60
- )
+ channelRateLimitCount = Math.max(
+ 0,
+ integerOrDefault(parsed.channel_rate_limit_count, 0)
+ )
+ channelRateLimitPeriodSeconds = Math.max(
+ 1,
+ integerOrDefault(parsed.channel_rate_limit_period_seconds, 60)
+ )📝 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
| channelRateLimitCount = integerOrDefault( | |
| parsed.channel_rate_limit_count, | |
| 0 | |
| ) | |
| channelRateLimitPeriodSeconds = integerOrDefault( | |
| parsed.channel_rate_limit_period_seconds, | |
| 60 | |
| ) | |
| channelRateLimitScope = | |
| parsed.channel_rate_limit_scope === 'key' ? 'key' : 'channel' | |
| channelRateLimitCount = Math.max( | |
| 0, | |
| integerOrDefault(parsed.channel_rate_limit_count, 0) | |
| ) | |
| channelRateLimitPeriodSeconds = Math.max( | |
| 1, | |
| integerOrDefault(parsed.channel_rate_limit_period_seconds, 60) | |
| ) | |
| channelRateLimitScope = | |
| parsed.channel_rate_limit_scope === 'key' ? 'key' : 'channel' |
🤖 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 `@web/default/src/features/channels/lib/channel-form.ts` around lines 239 -
248, transformChannelToFormDefaults currently assigns channelRateLimitCount and
channelRateLimitPeriodSeconds from parsed values but doesn't enforce the schema
lower bounds, which can create an invalid form state; update the assignment for
channelRateLimitCount, channelRateLimitPeriodSeconds (and channelRateLimitScope
if relevant) to clamp values so channelRateLimitCount >= 0 and
channelRateLimitPeriodSeconds >= 1 (and if your schema has upper bounds, also
clamp to those maxima) before returning the defaults.
zhibisora
marked this pull request as draft
May 23, 2026 08:47
(cherry picked from commit c8cbd5a69b1602aab81bcc7f08d8a90765a6bbb5)
zhibisora
force-pushed
the
upstream-main-channel-rate-limit
branch
from
July 22, 2026 06:49
b9c7c22 to
0579512
Compare
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
model/channel_cache.go (1)
308-341: 🩺 Stability & Availability | 🟠 Major | ⚡ Quick winBlocking DB write possible while holding the global
channelSyncLock.
channel.GetOtherSettings()can callchannel.Save()(a DB write) whenOtherSettingsfails to unmarshal. InCacheUpdateChannelthis call now happens whilechannelSyncLock.Lock()is held (lines 312-339), unlikeInitChannelCachewhere the equivalent call happens before the lock is acquired. SincechannelSyncLockalso gates the hotGetRandomSatisfiedChannelWithExclusionsread path used on every relay request, a slow/blocked DB write here would stall all concurrent channel selection. Thechannel == nilcheck is also performed after acquiring the lock, wasting a lock cycle on that path.🔒 Proposed fix: resolve config before acquiring the lock
func CacheUpdateChannel(channel *Channel) { if !common.MemoryCacheEnabled { return } - channelSyncLock.Lock() if channel == nil { - channelSyncLock.Unlock() return } + var newAdvancedConfig *dto.AdvancedCustomConfig + if channel.Type == constant.ChannelTypeAdvancedCustom { + newAdvancedConfig = channel.GetOtherSettings().AdvancedCustom + } + + channelSyncLock.Lock() if channelsIDM == nil { channelsIDM = make(map[int]*Channel) } if oldChannel, ok := channelsIDM[channel.Id]; ok { logger.LogDebug(nil, "CacheUpdateChannel before: id=%d, name=%s, status=%d, polling_index=%d", channel.Id, channel.Name, channel.Status, oldChannel.ChannelInfo.MultiKeyPollingIndex) } channelsIDM[channel.Id] = channel if channel2advancedCustomConfig == nil { channel2advancedCustomConfig = make(map[int]*dto.AdvancedCustomConfig) } delete(channel2advancedCustomConfig, channel.Id) - if channel.Type == constant.ChannelTypeAdvancedCustom { - if config := channel.GetOtherSettings().AdvancedCustom; config != nil { - channel2advancedCustomConfig[channel.Id] = config - } + if newAdvancedConfig != nil { + channel2advancedCustomConfig[channel.Id] = newAdvancedConfig } logger.LogDebug(nil, "CacheUpdateChannel after: id=%d, name=%s, status=%d, polling_index=%d", channel.Id, channel.Name, channel.Status, channel.ChannelInfo.MultiKeyPollingIndex) channelSyncLock.Unlock() InvalidatePricingCache() }🤖 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 `@model/channel_cache.go` around lines 308 - 341, In CacheUpdateChannel, validate channel == nil before acquiring channelSyncLock, then resolve channel.GetOtherSettings().AdvancedCustom before locking so any fallback Save occurs outside the global lock. After acquiring the lock, retain the cache map updates and use the precomputed advanced custom configuration when updating channel2advancedCustomConfig.
🤖 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 `@controller/channel.go`:
- Around line 467-471: Update the validation error returned by validateChannel
after channel.ValidateSettings() fails to remove the literal
“[setting/settings]” placeholder and use clear, user-facing Chinese wording
while preserving the underlying error details.
In `@docs/channel/other_setting.md`:
- Around line 20-21: Update the documentation entries for
channel_rate_limit_count and channel_rate_limit_period_seconds to state that,
when enabled, both values must be positive integers, not merely greater than
zero. Preserve the existing descriptions and clearly include the integer
requirement for each setting.
---
Outside diff comments:
In `@model/channel_cache.go`:
- Around line 308-341: In CacheUpdateChannel, validate channel == nil before
acquiring channelSyncLock, then resolve
channel.GetOtherSettings().AdvancedCustom before locking so any fallback Save
occurs outside the global lock. After acquiring the lock, retain the cache map
updates and use the precomputed advanced custom configuration when updating
channel2advancedCustomConfig.
🪄 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: CHILL
Plan: Pro
Run ID: 565a6fb6-67fc-4a7a-bffc-f8113ae6482f
📒 Files selected for processing (21)
common/limiter/limiter.gocommon/limiter/lua/rate_limit.luacontroller/channel.gocontroller/channel_rate_limit_retry_test.gocontroller/relay.gocontroller/task_error_response_test.godocs/channel/other_setting.mddto/channel_settings.gomiddleware/channel-rate-limit.gomiddleware/channel_rate_limit_test.gomiddleware/distributor.gomodel/ability.gomodel/channel.gomodel/channel_cache.gomodel/channel_key_test.gorelay/mjproxy_handler.gorelay/relay_task.gorelay/relay_task_test.goservice/channel.goservice/channel_select.goservice/error_test.go
🚧 Files skipped from review as they are similar to previous changes (12)
- common/limiter/lua/rate_limit.lua
- controller/channel_rate_limit_retry_test.go
- service/error_test.go
- common/limiter/limiter.go
- middleware/distributor.go
- relay/relay_task_test.go
- service/channel_select.go
- relay/relay_task.go
- relay/mjproxy_handler.go
- middleware/channel-rate-limit.go
- dto/channel_settings.go
- controller/relay.go
Comment on lines
467
to
471
| func validateChannel(channel *model.Channel, isAdd bool) error { | ||
| // 校验 channel settings | ||
| if err := channel.ValidateSettings(); err != nil { | ||
| return fmt.Errorf("渠道额外设置[channel setting] 格式错误：%s", err.Error()) | ||
| return fmt.Errorf("渠道设置[setting/settings] 格式错误：%s", err.Error()) | ||
| } |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Confusing placeholder text in validation error message.
"渠道设置[setting/settings] 格式错误：%s" mixes literal bracket notation into the user-facing Chinese message, likely a merge/placeholder artifact rather than intended copy.
✏️ Proposed fix
- return fmt.Errorf("渠道设置[setting/settings] 格式错误：%s", err.Error())
+ return fmt.Errorf("渠道设置格式错误：%s", err.Error())📝 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
| func validateChannel(channel *model.Channel, isAdd bool) error { | |
| // 校验 channel settings | |
| if err := channel.ValidateSettings(); err != nil { | |
| return fmt.Errorf("渠道额外设置[channel setting] 格式错误：%s", err.Error()) | |
| return fmt.Errorf("渠道设置[setting/settings] 格式错误：%s", err.Error()) | |
| } | |
| func validateChannel(channel *model.Channel, isAdd bool) error { | |
| // 校验 channel settings | |
| if err := channel.ValidateSettings(); err != nil { | |
| return fmt.Errorf("渠道设置格式错误：%s", err.Error()) | |
| } |
🤖 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 `@controller/channel.go` around lines 467 - 471, Update the validation error
returned by validateChannel after channel.ValidateSettings() fails to remove the
literal “[setting/settings]” placeholder and use clear, user-facing Chinese
wording while preserving the underlying error details.
Comment on lines
+20
to
+21
| - `channel_rate_limit_count`: 每周期允许的请求数；启用时必须大于 0 | ||
| - `channel_rate_limit_period_seconds`: 限流周期（秒）；启用时必须大于 0 |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Document the integer constraint for rate-limit values.
The backend and default UI require both channel_rate_limit_count and channel_rate_limit_period_seconds to be positive integers, but the documentation only says they must be greater than zero. Clarify this to prevent users from configuring rejected fractional values.
Proposed wording
- - `channel_rate_limit_count`: 每周期允许的请求数；启用时必须大于 0
- - `channel_rate_limit_period_seconds`: 限流周期（秒）；启用时必须大于 0
+ - `channel_rate_limit_count`: 每周期允许的请求数；启用时必须为大于 0 的整数
+ - `channel_rate_limit_period_seconds`: 限流周期（秒）；启用时必须为大于 0 的整数📝 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
| - `channel_rate_limit_count`: 每周期允许的请求数；启用时必须大于 0 | |
| - `channel_rate_limit_period_seconds`: 限流周期（秒）；启用时必须大于 0 | |
| - `channel_rate_limit_count`: 每周期允许的请求数；启用时必须为大于 0 的整数 | |
| - `channel_rate_limit_period_seconds`: 限流周期（秒）；启用时必须为大于 0 的整数 |
🤖 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 `@docs/channel/other_setting.md` around lines 20 - 21, Update the documentation
entries for channel_rate_limit_count and channel_rate_limit_period_seconds to
state that, when enabled, both values must be positive integers, not merely
greater than zero. Preserve the existing descriptions and clearly include the
integer requirement for each setting.
Closed
14 tasks
This was referenced Aug 1, 2026
This was referenced Aug 9, 2026
Open
11 tasks
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.
Summary
Testing
Summary by CodeRabbit
Release Notes