Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add api version and tls to adapter #610

Merged

Conversation

fntz
Copy link
Contributor

@fntz fntz commented Oct 15, 2024

Hi,
I added new methods: Version/TLS to adapter (issue: #590)

Summary by CodeRabbit

  • New Features

    • Enhanced context interfaces across multiple adapters to include methods for retrieving TLS connection states and HTTP protocol versions.
    • Introduced a new ProtoVersion type for encapsulating HTTP protocol details.
  • Bug Fixes

    • Improved middleware application for API instances to ensure consistent handling of HTTP context and version across adapters.

Copy link

coderabbitai bot commented Oct 15, 2024

Walkthrough

The changes introduced in this pull request enhance various adapter contexts by adding methods to retrieve TLS connection states and HTTP protocol version details. A new wrap function is introduced for middleware application across adapter instances. The Context interface is updated to include methods for TLS and version retrieval, and a new ProtoVersion type is defined. These modifications ensure consistent middleware application and improve the ability to handle HTTP requests with detailed connection and protocol information.

Changes

File Path Change Summary
adapters/adapters_test.go Added function wrap(h huma.API, isFiber bool) huma.API to apply middleware to API instances.
adapters/humabunrouter/humabunrouter.go Added methods TLS() and Version() to bunContext and bunCompatContext for TLS state and version info.
adapters/humachi/humachi.go Added methods TLS() and Version() to chiContext for TLS state and version info.
adapters/humaecho/humaecho.go Added methods TLS() and Version() to echoCtx for TLS state and version info.
adapters/humafiber/humafiber.go Added methods TLS() and Version() to fiberCtx for TLS state and version info.
adapters/humaflow/humaflow.go Added methods TLS() and Version() to goContext for TLS state and version info.
adapters/humagin/humagin.go Added methods TLS() and Version() to ginCtx for TLS state and version info.
adapters/humago/humago.go Added methods TLS() and Version() to goContext for TLS state and version info.
adapters/humahttprouter/humahttprouter.go Added methods TLS() and Version() to httprouterContext for TLS state and version info.
adapters/humamux/humamux.go Added methods TLS() and Version() to gmuxContext for TLS state and version info.
api.go Updated Context interface with methods TLS() and Version(), added ProtoVersion type for protocol info.

Poem

🐇 In the realm of code, where rabbits play,
New methods hop in, brightening the day.
TLS and versions, a dance they now do,
With wrap in the mix, our tests feel anew!
So let’s celebrate, with a joyful cheer,
For the changes made, bring us all near! 🎉


Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Outside diff range and nitpick comments (13)
adapters/humamux/humamux.go (1)

71-77: LGTM: Version() method implementation is correct with a minor optimization possible.

The Version() method correctly returns a huma.ProtoVersion struct containing the HTTP protocol version details from the request. This addition enhances the adapter's capabilities by providing access to protocol information, which can be useful for version-specific handling.

Consider a minor optimization by directly returning the struct:

func (c *gmuxContext) Version() huma.ProtoVersion {
	return huma.ProtoVersion{
		Proto:      c.r.Proto,
		ProtoMajor: c.r.ProtoMajor,
		ProtoMinor: c.r.ProtoMinor,
	}
}

This avoids the need for a named return value and is slightly more concise.

adapters/humahttprouter/humahttprouter.go (1)

115-121: LGTM: Version method implementation looks good. Consider a minor optimization.

The Version() method correctly constructs and returns a huma.ProtoVersion struct with the protocol version details from the http.Request. This implementation aligns with the PR objectives and enhances the adapter's functionality by providing access to HTTP version information.

Consider a minor optimization to reduce struct creation overhead:

 func (c *httprouterContext) Version() huma.ProtoVersion {
-	return huma.ProtoVersion{
-		Proto:      c.r.Proto,
-		ProtoMajor: c.r.ProtoMajor,
-		ProtoMinor: c.r.ProtoMinor,
-	}
+	return huma.ProtoVersion{Proto: c.r.Proto, ProtoMajor: c.r.ProtoMajor, ProtoMinor: c.r.ProtoMinor}
 }

This change reduces the number of lines and makes the struct initialization more concise without affecting readability.

adapters/humagin/humagin.go (1)

112-118: LGTM: Version method implementation looks good. Consider adding a comment.

The Version() method is correctly implemented, returning a huma.ProtoVersion struct with the appropriate protocol version details from the original request. This aligns with the PR objective.

Consider adding a brief comment explaining the purpose of this method, for example:

// Version returns the HTTP protocol version used in the request.
func (c *ginCtx) Version() huma.ProtoVersion {
    // ... (existing implementation)
}
adapters/humaecho/humaecho.go (1)

112-119: LGTM: Version method implementation looks good.

The Version() method correctly constructs and returns a huma.ProtoVersion object with the appropriate protocol version details from the original request. This implementation aligns with the PR objective to add API version to the adapter.

Consider a minor optimization for better readability:

 func (c *echoCtx) Version() huma.ProtoVersion {
-	r := c.orig.Request()
+	req := c.orig.Request()
 	return huma.ProtoVersion{
-		Proto:      r.Proto,
-		ProtoMajor: r.ProtoMajor,
-		ProtoMinor: r.ProtoMinor,
+		Proto:      req.Proto,
+		ProtoMajor: req.ProtoMajor,
+		ProtoMinor: req.ProtoMinor,
 	}
 }

This change uses a more descriptive variable name req instead of r, which slightly improves code readability.

adapters/adapters_test.go (2)

93-107: LGTM with suggestions for improvement

The wrap function is well-implemented and aligns with the PR objectives. It correctly adds middleware to check TLS and HTTP version, handling the Fiber adapter differently as needed. However, consider the following suggestions:

  1. Add more descriptive error messages to the assertions to aid in debugging if they fail.
  2. Consider handling the case where TLS might be present, even though it's not expected in the test environment.

Example of improved assertion:

assert.Nil(t, ctx.TLS(), "Expected TLS to be nil in test environment")

113-120: LGTM with a suggestion for improvement

The modifications to the adapter initialization are well-implemented. All adapters now consistently use the wrap function, ensuring that they are tested with the new middleware. The Fiber adapter is correctly identified with true as the second parameter.

Suggestion for improvement:
Consider replacing the boolean parameter with a more type-safe approach. This could help prevent potential errors and improve code readability. For example:

type AdapterType int

const (
    StandardAdapter AdapterType = iota
    FiberAdapter
)

wrap := func(h huma.API, adapterType AdapterType) huma.API {
    // ... (rest of the function remains the same)
}

// Usage:
{"fiber", func() huma.API { return wrap(humafiber.New(fiber.New(), config()), FiberAdapter) }},
// For other adapters:
{"chi", func() huma.API { return wrap(humachi.New(chi.NewMux(), config()), StandardAdapter) }},

This approach makes the code more self-documenting and reduces the chance of passing incorrect boolean values.

adapters/humaflow/humaflow.go (3)

107-109: LGTM: TLS method added correctly

The TLS() method is implemented correctly, providing access to the TLS connection state from the HTTP request. This aligns with the PR objectives.

Consider adding a comment to explain the purpose of this method, especially for cases where the connection might not be using TLS:

// TLS returns the TLS connection state if the connection
// is using TLS, otherwise it returns nil.
func (c *goContext) TLS() *tls.ConnectionState {
	return c.r.TLS
}

111-117: LGTM: Version method added correctly

The Version() method is implemented correctly, providing access to the HTTP protocol version information from the request. This aligns with the PR objectives.

Consider adding a comment to explain the purpose of this method and the structure it returns:

// Version returns the HTTP protocol version information
// encapsulated in a huma.ProtoVersion struct.
func (c *goContext) Version() huma.ProtoVersion {
	return huma.ProtoVersion{
		Proto:      c.r.Proto,
		ProtoMajor: c.r.ProtoMajor,
		ProtoMinor: c.r.ProtoMinor,
	}
}

5-5: Summary: Successful implementation of TLS and Version methods

The changes in this file successfully implement the new TLS() and Version() methods for the goContext struct. These additions enhance the adapter's functionality by providing access to TLS connection states and HTTP protocol version details, which aligns with the PR objectives.

The implementation is correct and the changes are well-integrated into the existing code structure. The new methods will allow users of this adapter to access important connection and protocol information, improving the overall capability of the system to handle HTTP requests with detailed context.

Consider updating the package documentation or README to highlight these new capabilities, ensuring that users are aware of the enhanced functionality provided by the adapter.

Also applies to: 107-117

api.go (3)

70-73: LGTM: Enhanced Context interface with TLS and Version methods

The addition of TLS() and Version() methods to the Context interface is well-implemented and aligns with the PR objectives. These methods will provide valuable information about the TLS connection state and HTTP protocol version.

Consider adding brief documentation comments for these new methods to improve code readability:

// TLS returns the TLS connection state, or nil if the connection is not TLS.
TLS() *tls.ConnectionState

// Version returns the HTTP protocol version used for the request.
Version() ProtoVersion

125-130: LGTM: New ProtoVersion struct for HTTP protocol version

The ProtoVersion struct is well-designed to represent HTTP protocol version information. The field names and types are appropriate and consistent with Go conventions.

Consider enhancing the documentation comment for better clarity:

// ProtoVersion represents the HTTP protocol version used in a request.
// It includes the full protocol string (e.g., "HTTP/1.1") and separate
// fields for major and minor version numbers.
type ProtoVersion struct {
	Proto      string // The protocol string (e.g., "HTTP/1.1")
	ProtoMajor int    // The major version number
	ProtoMinor int    // The minor version number
}

Line range hint 1-130: Summary: Successful implementation of TLS and Version support

The changes in this file effectively implement the PR objectives of adding API version and TLS support to the adapter. The modifications include:

  1. Adding the necessary "crypto/tls" import
  2. Enhancing the Context interface with TLS() and Version() methods
  3. Introducing a new ProtoVersion struct to represent HTTP protocol version information

These changes are well-integrated into the existing codebase and provide valuable additional information for request handling. The implementation follows Go best practices and conventions.

Consider updating any existing adapter implementations to support these new methods, ensuring consistent behavior across different HTTP routers and frameworks.

adapters/humafiber/humafiber.go (1)

115-117: Handle potential nil value from TLSConnectionState

The TLS() method correctly retrieves the TLS connection state using c.orig.Context().TLSConnectionState(). Please be aware that this method may return nil if the connection is not secured with TLS. Ensure that any code using TLS() checks for a nil value to avoid potential nil pointer dereferences.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 1c7affe and 0dc95c9.

📒 Files selected for processing (11)
  • adapters/adapters_test.go (1 hunks)
  • adapters/humabunrouter/humabunrouter.go (3 hunks)
  • adapters/humachi/humachi.go (2 hunks)
  • adapters/humaecho/humaecho.go (2 hunks)
  • adapters/humafiber/humafiber.go (2 hunks)
  • adapters/humaflow/humaflow.go (2 hunks)
  • adapters/humagin/humagin.go (2 hunks)
  • adapters/humago/humago.go (2 hunks)
  • adapters/humahttprouter/humahttprouter.go (2 hunks)
  • adapters/humamux/humamux.go (2 hunks)
  • api.go (3 hunks)
🧰 Additional context used
🔇 Additional comments (26)
adapters/humamux/humamux.go (3)

5-5: LGTM: Import addition is correct and necessary.

The addition of the crypto/tls import is appropriate for the new TLS() method implementation.


67-69: LGTM: TLS() method implementation is correct.

The TLS() method correctly returns the TLS connection state from the HTTP request. This addition enhances the adapter's capabilities by providing access to TLS information, which can be crucial for security-related operations.


Line range hint 1-145: Overall, the changes look good and align with the PR objectives.

The additions of TLS() and Version() methods to the gmuxContext struct enhance the adapter's capabilities by providing access to TLS connection states and HTTP protocol version details. These changes are well-implemented and will be useful for security-related operations and protocol-specific handling.

A minor optimization was suggested for the Version() method, but it's not critical. The code is clean, well-structured, and maintains the existing style of the file.

adapters/humahttprouter/humahttprouter.go (2)

111-113: LGTM: TLS method implementation looks good.

The TLS() method correctly returns the TLS connection state from the underlying http.Request. This implementation aligns with the PR objectives and enhances the adapter's functionality by providing access to TLS information.


111-121: Consider the implications on API design and backward compatibility.

The addition of TLS() and Version() methods to the httprouterContext struct enhances the adapter's functionality by providing access to TLS and HTTP version information. These changes align well with the PR objectives and the AI-generated summary.

However, it's important to consider the following:

  1. API Design: Ensure that these additions are consistent with the overall API design philosophy. Are similar methods available in other adapters? If not, consider whether they should be added for consistency across the project.

  2. Backward Compatibility: While these additions don't break existing code, they may impact the interface contract. Ensure that this expansion of the interface is documented and communicated to users, especially if httprouterContext is part of the public API.

  3. Usage Guidelines: Consider providing documentation or examples on when and how to use these new methods effectively.

To ensure consistency across the project, let's check if similar methods exist in other adapters:

This will help determine if similar methods exist in other adapters and whether further changes are needed for consistency.

✅ Verification successful

API Design and Backward Compatibility Verified

The addition of TLS() and Version() methods to the httprouterContext struct is consistent with other adapters in the codebase. Similar methods exist across various adapters, ensuring uniform API design and maintaining backward compatibility.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for TLS() and Version() methods in other adapter files

# Test: Search for TLS() method in other adapter files
echo "Searching for TLS() method in other adapters:"
rg --type go -g 'adapters/**/*.go' -n 'func \(.+\) TLS\(\)' --ignore-file adapters/humahttprouter/humahttprouter.go

echo "\nSearching for Version() method in other adapters:"
rg --type go -g 'adapters/**/*.go' -n 'func \(.+\) Version\(\)' --ignore-file adapters/humahttprouter/humahttprouter.go

Length of output: 14139


Script:

#!/bin/bash
# Description: Corrected script to check for TLS() and Version() methods in other adapter files

# Find all .go files in adapters/ excluding humahttprouter/humahttprouter.go
GO_FILES=$(fd --type f --extension go --search-path adapters/ --exclude humahttprouter/humahttprouter.go)

echo "Searching for TLS() method in other adapters:"
echo "$GO_FILES" | xargs rg -n 'func \(.+\) TLS\(\)'

echo -e "\nSearching for Version() method in other adapters:"
echo "$GO_FILES" | xargs rg -n 'func \(.+\) Version\(\)'

Length of output: 3844

adapters/humachi/humachi.go (4)

5-5: LGTM: Import addition is correct and necessary.

The addition of the crypto/tls import is appropriate for the new TLS() method implementation.


110-112: LGTM: TLS() method implementation is correct.

The TLS() method correctly returns the TLS connection state from the HTTP request. This implementation aligns with the PR objectives and enhances the adapter's functionality for handling secure connections.


114-120: LGTM: Version() method implementation is correct and comprehensive.

The Version() method correctly constructs and returns a huma.ProtoVersion struct containing all relevant protocol version details from the HTTP request. This implementation aligns with the PR objectives and provides valuable information about the HTTP protocol version used in the request.


5-5: Summary: Excellent implementation of TLS and Version methods.

The changes in this file successfully implement the new TLS() and Version() methods for the chiContext struct. These additions, along with the necessary crypto/tls import, enhance the adapter's capabilities by providing access to TLS connection states and HTTP protocol version details. The implementations are concise, correct, and align perfectly with the PR objectives.

These changes will improve the ability to handle HTTP requests with detailed connection and protocol information, which is valuable for various use cases, including security checks and protocol-specific handling.

Also applies to: 110-120

adapters/humagin/humagin.go (2)

108-110: LGTM: TLS method implementation looks good.

The TLS() method is correctly implemented, returning the TLS connection state from the original request. This aligns with the PR objective and matches the expected signature for the huma.Context interface.


108-118: Summary: New TLS and Version methods successfully implemented.

The changes in this file successfully add the TLS() and Version() methods to the ginCtx struct, fulfilling the PR objectives. Both methods are correctly implemented and enhance the adapter's functionality.

To ensure completeness, please verify:

  1. That corresponding unit tests have been added or updated for these new methods.
  2. That any relevant documentation (e.g., README, API docs) has been updated to reflect these new capabilities.

You can use the following script to check for test updates:

adapters/humaecho/humaecho.go (1)

108-110: LGTM: TLS method implementation looks good.

The TLS() method correctly returns the TLS connection state from the original request. This implementation aligns with the PR objective to add TLS to the adapter.

adapters/adapters_test.go (1)

Line range hint 1-120: Overall assessment: Well-implemented changes with minor suggestions for improvement

The changes in this file successfully implement the PR objectives of adding API version and TLS checks to the adapters. The new wrap function and its usage in adapter initialization ensure consistent behavior across all adapters. The implementation correctly handles the unique behavior of the Fiber adapter.

Key points:

  1. The wrap function effectively adds middleware to check TLS and HTTP version.
  2. All adapters now use the wrap function consistently.
  3. The changes align well with the PR objectives and enhance the testing of adapters.

The suggestions provided (more descriptive assertion messages, handling potential TLS presence, and using a type-safe approach for adapter type) are minor improvements that could further enhance the code quality and maintainability.

Great job on implementing these changes!

adapters/humaflow/humaflow.go (1)

5-5: LGTM: Import statement added correctly

The addition of the crypto/tls import is necessary and correctly placed for the new TLS() method.

adapters/humago/humago.go (4)

5-5: LGTM: Import addition for TLS functionality

The addition of the crypto/tls import is appropriate and necessary for the new TLS() method. This change aligns with the PR objectives of adding TLS functionality to the adapter.


116-118: LGTM: TLS method implementation

The TLS() method is correctly implemented, providing access to the TLS connection state from the underlying HTTP request. This addition enhances the adapter's capabilities for handling secure connections and aligns with the PR objectives.


120-126: LGTM: Version method implementation

The Version() method is well-implemented, providing a clean interface to access HTTP protocol version details. It correctly constructs and returns a huma.ProtoVersion struct with the relevant information from the underlying HTTP request. This addition enhances the adapter's functionality and aligns with the PR objectives.


5-5: Summary: Excellent additions enhancing adapter functionality

The changes introduced in this PR successfully add TLS and HTTP version information access to the goContext struct. These additions are well-implemented and align perfectly with the PR objectives. The new methods, TLS() and Version(), provide valuable information that can be used for security-related features and version-specific handling. The code is clean, concise, and maintains the existing structure of the adapter.

Great job on enhancing the adapter's capabilities!

Also applies to: 116-126

adapters/humabunrouter/humabunrouter.go (5)

5-5: LGTM: Import added correctly.

The crypto/tls import is correctly added and is necessary for the new TLS() method implementations.


111-121: LGTM: TLS and Version methods implemented correctly.

Both TLS() and Version() methods are implemented correctly:

  • TLS() returns the TLS connection state from the request.
  • Version() constructs and returns a huma.ProtoVersion struct with the correct protocol version details.

These implementations align with the PR objectives of adding API version and TLS to the adapter.


214-216: LGTM: TLS method for bunCompatContext implemented correctly.

The TLS() method for bunCompatContext is implemented correctly:

  • It returns the TLS connection state from the request.
  • The implementation is consistent with the bunContext version.

218-224: LGTM: Version method for bunCompatContext implemented correctly.

The Version() method for bunCompatContext is implemented correctly:

  • It constructs and returns a huma.ProtoVersion struct with the correct protocol version details.
  • The implementation is consistent with the bunContext version.

Line range hint 1-300: Summary: PR objectives successfully implemented.

The changes in this file successfully implement the PR objectives of adding API version and TLS to the adapter:

  1. The crypto/tls package is correctly imported.
  2. Both bunContext and bunCompatContext now have TLS() and Version() methods.
  3. The implementations are consistent across both context types.
  4. The new methods provide access to TLS connection state and HTTP protocol version details.

These additions enhance the adapter's functionality and align well with the stated PR objectives.

api.go (1)

5-5: LGTM: Import addition for TLS support

The addition of the "crypto/tls" import is appropriate and necessary for the new TLS() method in the Context interface.

adapters/humafiber/humafiber.go (2)

6-6: Importing the "crypto/tls" package is necessary for TLS support

The addition of the "crypto/tls" import is appropriate to support the new TLS() method, which returns the TLS connection state.


119-123: Version() method accurately implements protocol version retrieval

The Version() method appropriately constructs a huma.ProtoVersion with the protocol obtained from c.orig.Protocol(). This implementation aligns with the expected interface and provides accurate protocol version information.

Comment on lines +108 to +119
func (c *echoCtx) TLS() *tls.ConnectionState {
return c.orig.Request().TLS
}

func (c *echoCtx) Version() huma.ProtoVersion {
r := c.orig.Request()
return huma.ProtoVersion{
Proto: r.Proto,
ProtoMajor: r.ProtoMajor,
ProtoMinor: r.ProtoMinor,
}
}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codebase verification

Verification Complete: Methods are currently used only in test files.

The newly added TLS() and Version() methods are utilized within adapters/adapters_test.go for testing purposes. To fully leverage their functionality, consider integrating these methods into the production codebase where appropriate.

🔗 Analysis chain

Summary: New methods enhance adapter functionality.

The addition of TLS() and Version() methods to the echoCtx struct successfully implements the PR objectives. These methods provide valuable access to TLS connection state and HTTP protocol version information, enhancing the adapter's capabilities.

To ensure consistency, please verify the usage of these new methods across the codebase. Run the following script to check for potential usage:

This will help identify any existing code that might benefit from using these new methods.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for potential usage of new TLS() and Version() methods

# Test: Search for potential usage of TLS() method
echo "Potential usage of TLS() method:"
rg --type go "\.TLS\(\)" --glob '!adapters/humaecho/humaecho.go'

# Test: Search for potential usage of Version() method
echo "Potential usage of Version() method:"
rg --type go "\.Version\(\)" --glob '!adapters/humaecho/humaecho.go'

Length of output: 397

Copy link

codecov bot commented Oct 16, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.83%. Comparing base (f398d76) to head (ebd6bda).
Report is 8 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #610   +/-   ##
=======================================
  Coverage   92.83%   92.83%           
=======================================
  Files          22       22           
  Lines        3923     3923           
=======================================
  Hits         3642     3642           
  Misses        236      236           
  Partials       45       45           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Owner

@danielgtaylor danielgtaylor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great, thank you! 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants