Conversation
- Introduced `isError` getter for error checking on HTTP status codes. - Packaged AI assets for enhanced coding agent support. - Fixed various issues including null checks and regex patterns. - Updated documentation for clarity on handler priorities.
Add comprehensive documentation for API reference, functional patterns, and prompts related to handling HTTP responses and caching strategies.
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
- Updated `StatusCode.pattern` and `StatusCode.regExp` to match only valid HTTP status codes (100–599) instead of any three-digit number.
Owner
Author
|
@coderabbitai review |
Contributor
✅ Actions performedReview triggered.
|
Contributor
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughAdds release 3.2.0: public Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes 🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 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.
Pull request overview
Updates functional_status_codes to v3.2.0, adding a small API convenience (isError), tightening status-code parsing behavior, and shipping MCP-compatible packaged AI assets (resources + prompts) intended to help agents generate idiomatic usage of the library.
Changes:
- Bump package version to
3.2.0and add a detailedCHANGELOGentry for the release. - Update core helpers: add
num?.isError, tightenStatusCode.patternto100–599, and remove an unnecessary allocation inStatusCode.random(). - Add MCP packaged AI assets under
extension/mcp/(resources, prompts, and config).
Reviewed changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| pubspec.yaml | Version bump to 3.2.0. |
| lib/src/status_code.dart | Regex pattern tightened to 100–599; small random() implementation tweak; doc count updated. |
| lib/src/num_status_code_extension.dart | Add isError, clarify handler priority docs, and minor null/perf tweak in registered-mapping path. |
| extension/mcp/resources/patterns.md | New functional usage patterns guide for agents/users. |
| extension/mcp/resources/api_reference.md | New API cheat-sheet for agents/users. |
| extension/mcp/prompts/handle_response.md | New agent prompt to generate response-handling code. |
| extension/mcp/prompts/cache_strategy.md | New agent prompt to derive caching strategies from status codes. |
| extension/mcp/config.yaml | Registers MCP resources and prompts. |
| README.md | Removes trailing License section block from the end of the README. |
| CHANGELOG.md | Adds v3.2.0 release notes covering new API, fixes, and docs. |
Comments suppressed due to low confidence (1)
lib/src/status_code.dart:710
- The
regExpgetter documentation below still describes the old\d{3}behavior (“three consecutive digits” / “matches any three-digit number”), butpatternwas changed to[1-5]\d{2}. Please update theregExpdoc comment to match the new range-limited pattern and examples so users aren’t misled.
static const pattern = r'[1-5]\d{2}';
/// A getter that returns a [RegExp] object configured with a pattern to match
/// three consecutive digits, typically representing an HTTP status code.
///
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
You can also share your feedback on Copilot code review. Take the survey.
- Updated API reference with clearer examples for StatusCode usage. - Improved patterns guide to reflect changes in response handling. - Added tests for error handling in NumStatusCodeExtension.
![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: 7
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
lib/src/status_code.dart (1)
1253-1257:⚠️ Potential issue | 🟠 MajorSnapshot
frombefore sampling.This now walks non-list iterables twice: once for
length, then again forelementAt(). For lazy or stateful iterables, those two passes can see different data, so the sampled index no longer corresponds to a stable population. The previous snapshotting behavior was safer and matches the documented “any iterable type” support.🔧 Suggested fix
static StatusCode random({ Iterable<StatusCode> from = values, Random? random, }) { - assert(from.isNotEmpty, 'The provided `from` iterable must not be empty'); - final elementAt = (random ?? Random()).nextInt(from.length); - - // ignore: avoid-unsafe-collection-methods, length is guaranteed to be > 0. - return from.elementAt(elementAt); + final snapshot = List<StatusCode>.unmodifiable(from); + assert( + snapshot.isNotEmpty, + 'The provided `from` iterable must not be empty', + ); + final index = (random ?? Random()).nextInt(snapshot.length); + return snapshot[index]; }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/src/status_code.dart` around lines 1253 - 1257, The current code reads the iterable `from` twice (for `length` and for `elementAt`), which can produce inconsistent results for lazy/stateful iterables; snapshot `from` into a stable collection first (e.g., assign a local List like `snapshot = from is List ? from : from.toList()`), assert `snapshot.isNotEmpty`, compute the random index against `snapshot.length`, and return `snapshot.elementAt(elementAt)` (or `snapshot[elementAt]`) so both length and element access operate on the same materialized population; update the `assert` and the use of `elementAt`/`length` to use this snapshot variable.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@extension/mcp/prompts/cache_strategy.md`:
- Around line 30-40: The snippet calls whenConstOrNull on a raw int; convert the
rawCode to the StatusCode type first by calling toRegisteredStatusCode() (e.g.,
assign statusCode = rawCode.toRegisteredStatusCode()), then call whenConstOrNull
on that StatusCode (use a nullable call if toRegisteredStatusCode can return
null, e.g., statusCode?.whenConstOrNull(...)) to produce ttl; apply the same
change for the other occurrence that also calls whenConstOrNull on a numeric
value.
In `@extension/mcp/prompts/handle_response.md`:
- Around line 38-41: Update the prompt guidance so it no longer describes the
whenConst* APIs as callback-based: explicitly state that whenConstStatusCode and
whenConstOrNull accept direct constant values (and should be used with const),
not closures, and instruct agents to avoid generating () => branches; preserve
the recommendation to prefer const values for constant returns and to use ?. /
?? and .isSuccess/.isError/.isCacheable instead of manual null-checks or numeric
ranges.
In `@extension/mcp/resources/api_reference.md`:
- Around line 136-144: The examples use incorrect parameters for the `num`
extension APIs: `whenConstStatusCode` does not accept an `orElse` argument, and
`mapToRegisteredStatusCode` does not take `mapper`/`orElse` but instead accepts
category callback keys (`isInformational`, `isSuccess`, `isRedirection`,
`isClientError`, `isServerError`). Update the
`response.statusCode.whenConstStatusCode` example to only pass the direct value
arguments (remove `orElse`), and update the
`response.statusCode.mapToRegisteredStatusCode` example to pass callbacks for
each category (e.g. `isInformational: () => 'info'`, etc.) so the examples match
the actual `whenConstStatusCode` and `mapToRegisteredStatusCode` signatures.
In `@extension/mcp/resources/patterns.md`:
- Around line 188-200: The tests call helpers with the wrong signatures: provide
a parseBody callback when calling handleResponse (e.g., pass a simple closure
matching the required parseBody param) and mark the cache test as async and
await the async fetchAndCache call; update the test that uses fetchAndCache to
be declared async and change fetchAndCache('key', () async =>
Response(statusCode: code)) to await fetchAndCache(...). Target the failing
calls to handleResponse(...) and fetchAndCache(...) in the tests so the correct
argument types and async/await usage are applied.
- Around line 86-96: The documentation example uses whenConstStatusCode with an
orElse argument which is invalid; update the snippet to call
whenConstStatusCodeOrNull instead (keep the same named parameters
isInformational, isSuccess, isRedirection, isClientError, isServerError and the
orElse value) so the example matches the correct method signature.
- Around line 7-23: The example's handleResponse declares Future<T?> but returns
a synchronous value from statusCode.maybeMapStatusCode; change the signature to
T? handleResponse<T>(int statusCode, T Function() parseBody) (or alternatively
make the function async and return Future.value(...)) and add the missing import
for dart:io so HttpException resolves; ensure the existing import for
StatusCode/functional_status_codes remains. Reference: handleResponse,
maybeMapStatusCode, HttpException, StatusCode.
In `@lib/src/status_code.dart`:
- Around line 686-706: The regex pattern constant pattern currently uses an
unanchored '[1-5]\d{2}', which allows matching substrings inside longer numbers
(e.g., '6100' → '100') and thus causes tryParse to accept invalid input; change
the pattern to be anchored to match exactly a three-digit HTTP status (e.g., use
'^' and '$' around the existing class), ensure tryParse uses that anchored
pattern, and update the regExp documentation text below (mentions '\d{3}' / "any
three-digit number") to explicitly state the pattern is anchored and matches
only a full three-digit status code in the 100–599 range (no substring matches).
---
Outside diff comments:
In `@lib/src/status_code.dart`:
- Around line 1253-1257: The current code reads the iterable `from` twice (for
`length` and for `elementAt`), which can produce inconsistent results for
lazy/stateful iterables; snapshot `from` into a stable collection first (e.g.,
assign a local List like `snapshot = from is List ? from : from.toList()`),
assert `snapshot.isNotEmpty`, compute the random index against
`snapshot.length`, and return `snapshot.elementAt(elementAt)` (or
`snapshot[elementAt]`) so both length and element access operate on the same
materialized population; update the `assert` and the use of `elementAt`/`length`
to use this snapshot variable.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 72fa8006-23cd-4de5-8a29-a10f05437e10
📒 Files selected for processing (10)
CHANGELOG.mdREADME.mdextension/mcp/config.yamlextension/mcp/prompts/cache_strategy.mdextension/mcp/prompts/handle_response.mdextension/mcp/resources/api_reference.mdextension/mcp/resources/patterns.mdlib/src/num_status_code_extension.dartlib/src/status_code.dartpubspec.yaml
💤 Files with no reviewable changes (1)
- README.md
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
lib/src/status_code.dart (1)
1250-1258: 🧹 Nitpick | 🔵 TrivialAvoid double-traversing arbitrary iterables in
random().This method advertises
Iterable<StatusCode>, andtest/src/status_code_test.dart:165-180passes a lazywhere(...).take(5)iterable.from.lengthplusfrom.elementAt(...)walks that iterable twice and re-evaluates the pipeline. Materialize once whenfromis not already a list.Refactor sketch
static StatusCode random({ Iterable<StatusCode> from = values, Random? random, }) { - assert(from.isNotEmpty, 'The provided `from` iterable must not be empty'); - final elementAt = (random ?? Random()).nextInt(from.length); - - // ignore: avoid-unsafe-collection-methods, length is guaranteed to be > 0. - return from.elementAt(elementAt); + final codes = + from is List<StatusCode> ? from : from.toList(growable: false); + assert(codes.isNotEmpty, 'The provided `from` iterable must not be empty'); + final index = (random ?? Random()).nextInt(codes.length); + return codes[index]; }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/src/status_code.dart` around lines 1250 - 1258, The StatusCode.random method currently traverses the provided Iterable twice (using from.length and from.elementAt) which can re-evaluate lazy pipelines; to fix, materialize the iterable once when it's not already a List: inside StatusCode.random create a local variable (e.g., final elements = from is List<StatusCode> ? from : from.toList()), keep the assert against elements.isNotEmpty, then use elements.length and return elements[elementAt]; this ensures single traversal and correct indexing for lazy iterables.
♻️ Duplicate comments (4)
extension/mcp/resources/patterns.md (2)
86-96:⚠️ Potential issue | 🟠 MajorUse the nullable const variant here.
whenConstStatusCodedoes not acceptorElse, so this snippet will not compile. Switch the example towhenConstStatusCodeOrNullif you want a fallback value.Suggested doc fix
-Category-level const mapping via `whenConstStatusCode`: +Category-level const mapping via `whenConstStatusCodeOrNull`: ```dart -final label = rawCode.whenConstStatusCode( +final label = rawCode.whenConstStatusCodeOrNull( isInformational: 'informational', isSuccess: 'success', isRedirection: 'redirect', isClientError: 'client error', isServerError: 'server error', orElse: 'unknown', );🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@extension/mcp/resources/patterns.md` around lines 86 - 96, The example uses whenConstStatusCode with an orElse (which is invalid); change the call on rawCode to the nullable variant whenConstStatusCodeOrNull and either provide the fallback by coalescing the result (e.g., ?? 'unknown') or remove the orElse param, so update the label assignment to call whenConstStatusCodeOrNull and handle null fallback externally.
188-200:⚠️ Potential issue | 🟠 MajorThese test snippets still do not match the helpers defined above.
handleResponseneeds theparseBodycallback,fetchAndCachemust be awaited from anasynctest, and the expectations are wrong for the current helper: it only returnsnullfor 404, whileStatusCode.custom(999)violates the constructor range and would hitorElse/throw instead.Also applies to: 211-216
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@extension/mcp/resources/patterns.md` around lines 188 - 200, Update the tests to match the helper signatures and valid StatusCode ranges: call handleResponse with a parseBody callback (e.g., handleResponse(code, parseBody: () => ...)) and change the second test to be async and await fetchAndCache('key', () async => Response(statusCode: code)); also adjust expectations so you only assert null for the specific 404 case (not every client error) and ensure StatusCode.random is constrained to valid ranges (avoid constructing invalid codes like StatusCode.custom(999) that hit orElse/throw) or replace random usage with explicit valid codes from StatusCode.clientErrorCodes and StatusCode.cacheableCodes.extension/mcp/resources/api_reference.md (1)
133-153:⚠️ Potential issue | 🟠 MajorThese API examples still use signatures the package does not ship.
whenConstStatusCodehas noorElseparameter, andmapToRegisteredStatusCodedoes not acceptmapper/orElse. As written, both examples are uncompilable.Possible doc direction
-// Const-value variant (no closures — direct values) -response.statusCode.whenConstStatusCode( +// Const-value variant with fallback +response.statusCode.whenConstStatusCodeOrNull( isInformational: 'info', isSuccess: 'ok', isRedirection: 'redirect', isClientError: 'client error', isServerError: 'server error', orElse: 'unknown', )-// Convert then map in one step -response.statusCode.mapToRegisteredStatusCode( - mapper: (statusCode) => statusCode.reason, - orElse: (raw) => 'Unknown: $raw', -) +// Convert, then read the registered reason when available +response.statusCode.toRegisteredStatusCode()?.reason ?? + 'Unknown: ${response.statusCode}'🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@extension/mcp/resources/api_reference.md` around lines 133 - 153, The docs use wrong function signatures: update the examples to match the actual API for whenConstStatusCode, whenConstStatusCodeOrNull, and mapToRegisteredStatusCode by removing non-existent named parameters and using the real parameter names/positional form; specifically, remove the orElse named argument from whenConstStatusCode examples, show whenConstStatusCodeOrNull usage that handles a nullable return (e.g., check for null instead of passing orElse), and replace the mapToRegisteredStatusCode example to call it with the actual parameter shape the package exposes (use the real parameter name or positional lambda and the correct fallback mechanism the function provides) so the snippets compile as-is.lib/src/status_code.dart (1)
706-734:⚠️ Potential issue | 🟠 Major
tryParse()still accepts inner substrings of larger numbers.With an unanchored
[1-5]\d{2}andfirstMatch, inputs like6100or2000can still parse as100or200. If substring extraction from prose is intentional,tryParseneeds a non-digit boundary check instead of using the first regex hit blindly.Also applies to: 769-773
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/src/status_code.dart` around lines 706 - 734, The regExp currently uses an unanchored pattern '[1-5]\d{2}', which allows matching substrings inside larger numbers (e.g., '6100' -> '100'); update the pattern used by RegExp (and the related usage in tryParse) to require non-digit boundaries so the match is not part of a larger numeric token (e.g., use lookarounds like (?<!\d)([1-5]\d{2})(?!\d) or equivalent) and adjust tryParse to extract the captured group rather than blindly taking a firstMatch that could be a substring; apply the same fix to the other occurrence noted (around the tryParse implementation at lines ~769-773).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@extension/mcp/resources/api_reference.md`:
- Around line 33-42: The docs claim StatusCode.officialCodes is the
"IANA-registered subset" but the implementation of StatusCode.officialCodes
includes unofficial entries (e.g., StatusCode.siteIsFrozenHttp530 and
StatusCode.nginxClientClosedRequestHttp499); either update the documentation
text in the API reference to remove the strict "IANA-registered" wording or
modify the StatusCode.officialCodes collection to remove non-IANA codes (scan
StatusCode.officialCodes in status_code.dart and drop any entries not officially
IANA-registered such as siteIsFrozenHttp530 and
nginxClientClosedRequestHttp499), then run tests/lint to ensure no references
break and update the enum/collection comment to reflect the chosen behavior.
---
Outside diff comments:
In `@lib/src/status_code.dart`:
- Around line 1250-1258: The StatusCode.random method currently traverses the
provided Iterable twice (using from.length and from.elementAt) which can
re-evaluate lazy pipelines; to fix, materialize the iterable once when it's not
already a List: inside StatusCode.random create a local variable (e.g., final
elements = from is List<StatusCode> ? from : from.toList()), keep the assert
against elements.isNotEmpty, then use elements.length and return
elements[elementAt]; this ensures single traversal and correct indexing for lazy
iterables.
---
Duplicate comments:
In `@extension/mcp/resources/api_reference.md`:
- Around line 133-153: The docs use wrong function signatures: update the
examples to match the actual API for whenConstStatusCode,
whenConstStatusCodeOrNull, and mapToRegisteredStatusCode by removing
non-existent named parameters and using the real parameter names/positional
form; specifically, remove the orElse named argument from whenConstStatusCode
examples, show whenConstStatusCodeOrNull usage that handles a nullable return
(e.g., check for null instead of passing orElse), and replace the
mapToRegisteredStatusCode example to call it with the actual parameter shape the
package exposes (use the real parameter name or positional lambda and the
correct fallback mechanism the function provides) so the snippets compile as-is.
In `@extension/mcp/resources/patterns.md`:
- Around line 86-96: The example uses whenConstStatusCode with an orElse (which
is invalid); change the call on rawCode to the nullable variant
whenConstStatusCodeOrNull and either provide the fallback by coalescing the
result (e.g., ?? 'unknown') or remove the orElse param, so update the label
assignment to call whenConstStatusCodeOrNull and handle null fallback
externally.
- Around line 188-200: Update the tests to match the helper signatures and valid
StatusCode ranges: call handleResponse with a parseBody callback (e.g.,
handleResponse(code, parseBody: () => ...)) and change the second test to be
async and await fetchAndCache('key', () async => Response(statusCode: code));
also adjust expectations so you only assert null for the specific 404 case (not
every client error) and ensure StatusCode.random is constrained to valid ranges
(avoid constructing invalid codes like StatusCode.custom(999) that hit
orElse/throw) or replace random usage with explicit valid codes from
StatusCode.clientErrorCodes and StatusCode.cacheableCodes.
In `@lib/src/status_code.dart`:
- Around line 706-734: The regExp currently uses an unanchored pattern
'[1-5]\d{2}', which allows matching substrings inside larger numbers (e.g.,
'6100' -> '100'); update the pattern used by RegExp (and the related usage in
tryParse) to require non-digit boundaries so the match is not part of a larger
numeric token (e.g., use lookarounds like (?<!\d)([1-5]\d{2})(?!\d) or
equivalent) and adjust tryParse to extract the captured group rather than
blindly taking a firstMatch that could be a substring; apply the same fix to the
other occurrence noted (around the tryParse implementation at lines ~769-773).
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 61effb88-8a0e-4b7a-a829-cc7be158f59b
📒 Files selected for processing (5)
extension/mcp/resources/api_reference.mdextension/mcp/resources/patterns.mdlib/src/num_status_code_extension.dartlib/src/status_code.darttest/src/num_status_code_extension_test.dart
- Clarified usage of `whenConstOrNull` and `toRegisteredStatusCode()` - Improved regex pattern for status code matching with negative lookarounds - Enhanced test cases for regex pattern validation
- Clarified the description of officialCodes in api_reference.md - Updated tests in patterns.md to focus on specific status codes - Improved list creation in status_code.dart for better performance
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
extension/mcp/resources/api_reference.md (1)
33-42:⚠️ Potential issue | 🟡 MinorDocumentation inaccuracy:
officialCodesincludes unofficial codes.The comment describes
StatusCode.officialCodesas the "IANA-registered subset", but the actual implementation inlib/src/status_code.dartincludes unofficial codes such assiteIsFrozenHttp530,nginxClientClosedRequestHttp499, and other vendor-specific codes.Consider either:
- Updating the documentation to accurately describe what the collection contains
- Or renaming/refactoring the collection in the source code
🔧 Suggested documentation fix
-StatusCode.officialCodes // IANA-registered subset +StatusCode.officialCodes // Commonly recognized codes (includes some vendor-specific)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@extension/mcp/resources/api_reference.md` around lines 33 - 42, Update the inaccurate doc comment for StatusCode.officialCodes to reflect that it contains both IANA-registered and vendor/unofficial codes (e.g., "IANA-registered and vendor-specific/unofficial codes"), or alternatively rename/refactor the collection in the code (StatusCode.officialCodes) to a clearer identifier (e.g., StatusCode.officialAndVendorCodes) and update all references and documentation to match; locate the symbol StatusCode.officialCodes (and related collections like StatusCode.informationalCodes, StatusCode.successCodes) and change the doc string in the API reference or the collection name in the implementation and adjust usages accordingly.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@extension/mcp/prompts/cache_strategy.md`:
- Line 1: Add a top-level Markdown heading to the prompt template to satisfy
markdownlint: insert a line like "# Cache Strategy Prompt" (or similar) above
the existing content that begins "Derive a caching strategy for HTTP status code
**{{status_code}}**..." so the file contains a clear top-level heading while
preserving the Mustache variable {{status_code}} and the rest of the prompt
text.
In `@lib/src/status_code.dart`:
- Around line 686-707: Update the doc comment around the static const pattern to
avoid the flagged word "lookarounds": replace occurrences of "lookarounds" with
"lookahead/lookbehind assertions" (or similar phrasing) in the documentation for
pattern (and any other comments referencing the regex), ensuring references to
RegExp, StatusCode, and maybeFromCode remain intact and wording remains clear;
do not add code, only change the comment text so the spellchecker passes.
---
Duplicate comments:
In `@extension/mcp/resources/api_reference.md`:
- Around line 33-42: Update the inaccurate doc comment for
StatusCode.officialCodes to reflect that it contains both IANA-registered and
vendor/unofficial codes (e.g., "IANA-registered and vendor-specific/unofficial
codes"), or alternatively rename/refactor the collection in the code
(StatusCode.officialCodes) to a clearer identifier (e.g.,
StatusCode.officialAndVendorCodes) and update all references and documentation
to match; locate the symbol StatusCode.officialCodes (and related collections
like StatusCode.informationalCodes, StatusCode.successCodes) and change the doc
string in the API reference or the collection name in the implementation and
adjust usages accordingly.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 31b8e9de-2a39-4d98-8204-0c69326dda99
📒 Files selected for processing (6)
extension/mcp/prompts/cache_strategy.mdextension/mcp/prompts/handle_response.mdextension/mcp/resources/api_reference.mdextension/mcp/resources/patterns.mdlib/src/status_code.darttest/src/status_code_test.dart
Updated the comments to clarify the use of negative look-ahead and look-behind assertions in the regex pattern for matching HTTP status codes.
tsinis
dismissed stale reviews from coderabbitai[bot] and github-actions[bot]
via
ae828e8
The pattern now specifies negative look-ahead and look-behind assertions to ensure accurate extraction of HTTP status codes from text.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #124 +/- ##
=======================================
Coverage 99.56% 99.57%
=======================================
Files 3 3
Lines 1395 1397 +2
=======================================
+ Hits 1389 1391 +2
Misses 6 6 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
This was referenced Mar 14, 2026
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
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.
Description
Type of Change
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Tests
Chores