fix: Use rustls tls in stellar client

[LuisUrrutia]

Summary

• TLS 1.3 Support: Modified HTTP client builder in Stellar provider to use rustls backend

Testing Process

Checklist

• Add a reference to related issues in the PR description.
• Add unit tests if applicable.

Note

If you are using Relayer in your stack, consider adding your team or organization to our list of Relayer Users in the Wild!

Summary by CodeRabbit

• Chores
  • Enhanced TLS configuration for secure HTTP connections.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

This change adds Rustls TLS configuration to the Stellar provider's HTTP JSON-RPC client initialization. The use_rustls_tls() method is invoked on the ReqwestClient builder, enabling Rustls TLS support for raw HTTP JSON-RPC calls without modifying public APIs or control flow logic.

Changes

Cohort / File(s)	Change Summary
Stellar Provider TLS Configuration src/services/provider/stellar/mod.rs	Added use_rustls_tls() to ReqwestClient builder in initialize_raw_provider to enable Rustls TLS for HTTP JSON-RPC communication

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Possibly related PRs

• feat(polkadot): Add Polkadot testnet and TLS 1.3 compatibility #525: Applies the same use_rustls_tls() configuration to the ReqwestClient builder in a different provider module, suggesting a consistent TLS enablement pattern across providers.

Suggested labels

cla: allowlist

Suggested reviewers

• tirumerla
• shahnami

Poem

🐰 A rabbit hops through TLS trees,
Rustls whispers on the breeze,
JSON-RPC calls now shine so bright,
Stellar provider locked up tight! ✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description includes the Summary section with relevant details about the rustls backend change, but the Testing Process section is empty and critical checklist items remain unchecked without explanation.	Complete the Testing Process section with actual testing details and address the checklist items by either checking them off or explaining why they don't apply to this change.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: enabling rustls TLS in the stellar client, which directly matches the code modification adding use_rustls_tls() to the HTTP client builder.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/stellar_tsl

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

src/services/provider/stellar/mod.rs (1)

377-390: Verify reqwest feature configuration is in place and consider documenting the TLS backend choice.

The .use_rustls_tls() addition is correct—the rustls-tls feature is already enabled in Cargo.toml. To improve maintainability, add a brief comment explaining the rustls choice, following the pattern already used in the EVM provider module:

// Using use_rustls_tls() forces the use of rustls instead of native-tls to support TLS 1.3
.use_rustls_tls()

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between bac5960 and 9638c9f.

📒 Files selected for processing (1)

• src/services/provider/stellar/mod.rs (1 hunks)

🧰 Additional context used

📓 Path-based instructions (1)

**/*.rs

📄 CodeRabbit inference engine (.cursor/rules/rust_standards.mdc)

**/*.rs: Follow official Rust style guidelines using rustfmt (edition = 2021, max_width = 100)
Follow Rust naming conventions: snake_case for functions/variables, PascalCase for types, SCREAMING_SNAKE_CASE for constants and statics
Order imports alphabetically and group by: std, external crates, local crates
Include relevant doc comments (///) on public functions, structs, and modules. Use comments for 'why', not 'what'. Avoid redundant doc comments
Document lifetime parameters when they're not obvious
Avoid unsafe code unless absolutely necessary; justify its use in comments
Write idiomatic Rust: Prefer Result over panic, use ? operator for error propagation
Avoid unwrap; handle errors explicitly with Result and custom Error types for all async operations
Prefer header imports over function-level imports of dependencies
Prefer borrowing over cloning when possible
Use &str instead of &String for function parameters
Use &[T] instead of &Vec for function parameters
Avoid unnecessary .clone() calls
Use Vec::with_capacity() when size is known in advance
Use explicit lifetimes only when necessary; infer where possible
Always use Tokio runtime for async code. Await futures eagerly; avoid blocking calls in async contexts
Streams: Use futures::StreamExt for processing streams efficiently
Always use serde for JSON serialization/deserialization with #[derive(Serialize, Deserialize)]
Use type aliases for complex types to improve readability
Implement common traits (Debug, Clone, PartialEq) where appropriate, using derive macros when possible
Implement Display for user-facing types
Prefer defining traits when implementing services to make mocking and testing easier
For tests, prefer existing utils for creating mocks instead of duplicating code
Use assert_eq! and assert! macros appropriately
Keep tests minimal, deterministic, and fast
Use tracing for structured logging, e.g., tracing::info! for request and error logs
When optimizing, prefer clarity first, then performance
M...

Files:

• src/services/provider/stellar/mod.rs

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (10)

• GitHub Check: msrv
• GitHub Check: Unit Tests
• GitHub Check: clippy
• GitHub Check: Properties Tests
• GitHub Check: boostsecurity - boostsecurityio/semgrep-pro
• GitHub Check: Redirect rules - openzeppelin-relayer
• GitHub Check: Header rules - openzeppelin-relayer
• GitHub Check: Pages changed - openzeppelin-relayer
• GitHub Check: Analyze (rust)
• GitHub Check: semgrep/ci

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.2%. Comparing base (26e66a2) to head (9638c9f).
⚠️ Report is 8 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##            main    #596     +/-   ##
=======================================
- Coverage   92.3%   92.2%   -0.1%     
=======================================
  Files        250     250             
  Lines      89798   90033    +235     
=======================================
+ Hits       82901   83093    +192     
- Misses      6897    6940     +43     

Flag	Coverage Δ
ai	0.3% <0.0%> (?)
dev	92.2% <100.0%> (?)
integration	?
properties	<0.1% <0.0%> (ø)
unittests	?

Flags with carried forward coverage won't be shown. Click here to find out more.

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[tirumerla]

lgtm