Simplify generic constraints in push policy tests

[coderabbitai]

A suggestion was made to simplify the generic constraints in the dlq_error_scenarios function in tests/push_policies.rs around lines 156-157.

The current approach using BoxFuture adds complexity and explicit lifetime management. The suggestion is to replace the BoxFuture return type with async closures using higher-ranked trait bounds (for<'a>) and returning an impl Future instead.

This would simplify the code by leveraging async closures and removing the need for boxing and explicit lifetimes.

References:

• PR: Implement push queue DLQ #198
• Comment: Implement push queue DLQ #198 (comment)
• Requested by: @leynos
• Issue: Simplify generic constraints in push policy tests #199

[leynos]

@coderabbitai looking at the codebase, is this issue still relevant? If the issue has been fixed in the code, does the documentation reflect this?

If it is still relevant, please provide an assessment of the impact of the required changes.

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

I'll help you assess the relevance of issue #199. Let me start by examining the issue details and then check the current codebase.

---

🏁 Script executed:

#!/bin/bash
# Fetch the details of issue #199
gh issue view 199 --json title,body,state,labels,createdAt,updatedAt

Length of output: 986

---

Now I understand the issue. It's about simplifying generic constraints in the dlq_error_scenarios function in tests/push_policies.rs. Let me examine the current state of this code.

---

🏁 Script executed:

#!/bin/bash
# First, let's check if the file exists and examine the dlq_error_scenarios function
fd "push_policies.rs" --type f

# Then look at the specific lines mentioned (around 156-157)
if [ -f "tests/push_policies.rs" ]; then
    echo "=== Examining tests/push_policies.rs around lines 156-157 ==="
    sed -n '150,170p' tests/push_policies.rs
    echo ""
    echo "=== Searching for dlq_error_scenarios function ==="
    rg -A 10 -B 2 "fn dlq_error_scenarios" tests/push_policies.rs
fi

Length of output: 932

---

Perfect! I can see the dlq_error_scenarios function still exists and is using BoxFuture<'_, ()> exactly as described in the issue. Let me get more context about the current implementation and check for any related documentation.

---

🏁 Script executed:

#!/bin/bash
# Get the complete function signature and some implementation context
echo "=== Complete dlq_error_scenarios function context ==="
rg -A 20 -B 5 "fn dlq_error_scenarios" tests/push_policies.rs

echo ""
echo "=== Checking for BoxFuture imports and usage ==="
rg "BoxFuture" tests/push_policies.rs

echo ""
echo "=== Checking for any documentation about async patterns ==="
fd "README.md" -x cat {} \; 2>/dev/null || echo "No README.md found"

echo ""
echo "=== Check if there are other similar patterns in the codebase ==="
rg "BoxFuture" --type rust -A 2 -B 2

Length of output: 15220

---

@leynos, after examining the codebase, issue #199 is still highly relevant and has not been addressed. Here's my comprehensive assessment:

Current State Analysis

The dlq_error_scenarios function in tests/push_policies.rs still uses the exact BoxFuture pattern described in the issue:

fn dlq_error_scenarios<Setup, AssertFn>(
    // ... parameters
) where
    Setup: FnOnce(&mpsc::Sender<u8>, &mut Option<mpsc::Receiver<u8>>),
    AssertFn: FnOnce(&mut Option<mpsc::Receiver<u8>>) -> BoxFuture<'_, ()>,

The helper functions still require explicit boxing:

fn assert_dlq_full(rx: &mut Option<mpsc::Receiver<u8>>) -> BoxFuture<'_, ()> {
    Box::pin(async move { /* ... */ })
}

fn assert_dlq_closed(_: &mut Option<mpsc::Receiver<u8>>) -> BoxFuture<'_, ()> { 
    Box::pin(async {}) 
}

Documentation Status

The documentation does not reflect any async testing patterns or guidelines. The README.md focuses on the library's API but doesn't address internal testing strategies or async closure patterns.

Impact Assessment of Required Changes

Low to Medium Impact - Scope is limited but beneficial

Affected Areas:

• Primary: tests/push_policies.rs (2 helper functions + 1 generic constraint)
• Potentially: Similar patterns in tests/preamble.rs and src/server.rs

Benefits:

1. Reduced complexity: Eliminates explicit Box::pin wrapping
2. Better ergonomics: Async closures are more natural to write
3. Improved maintainability: Less boilerplate in test helper functions
4. Consistency: Aligns with modern Rust async patterns

Risks:

• Low risk: Changes are isolated to test code
• Compilation: May require adjusting closure signatures in test cases
• Learning curve: Team familiarity with higher-ranked trait bounds (for<'a>)

Broader Pattern Analysis

The codebase uses BoxFuture in three locations:

1. Tests (tests/push_policies.rs) - the main issue target
2. Preamble callbacks (src/server.rs, tests/preamble.rs) - production code

The production usage in src/server.rs might benefit from the same pattern, but that would require more careful consideration due to API stability concerns.

Recommendation

Proceed with the implementation. The issue addresses a legitimate code quality improvement with minimal risk. The changes would modernize the async testing patterns and reduce boilerplate without affecting the library's public API.

Consider extending the improvement to the preamble callback patterns if appropriate, but prioritize the test code as originally scoped.

[leynos]

Unable to simplify the dlq_error_scenarios generics as suggested because stable Rust doesn’t yet support using impl Future as the return type in higher-ranked FnOnce bounds. Attempts with type aliases (type_alias_impl_trait) also failed because this feature is unstable and unavailable in the project. The existing BoxFuture pattern remains required for compilation.

[leynos]

@coderabbitai what is the upstream tracking issue for this?

Unable to simplify the dlq_error_scenarios generics as suggested because stable Rust doesn’t yet support using impl Future as the return type in higher-ranked FnOnce bounds. Attempts with type aliases (type_alias_impl_trait) also failed because this feature is unstable and unavailable in the project. The existing BoxFuture pattern remains required for compilation.

[coderabbitai]

🧩 Analysis chain

🌐 Web query:

rust impl trait return type higher ranked trait bounds HRTB tracking issue

💡 Result:

• The main Rust tracking issue that covers impl Trait (including the long-standing limitation that it’s not allowed inside higher-ranked bounds / for<...> contexts such as impl Fn(impl Trait) and similar “nested impl Trait” cases) is Tracking issue for RFC 1951: Finalize syntax and parameter scoping for impl Trait, while expanding it to arguments rust-lang/rust#42183 (“Tracking issue for RFC 1951: … expand impl Trait …”). [1]

• The more recent tracking issue specifically tied to precise capturing (use<...>) for RPIT/opaque impl Trait—which directly intersects with HRTB capture (e.g., “impl Trait cannot capture higher-ranked lifetime from outer impl Trait”)—is Tracking issue for precise_capturing syntax rust-lang/rust#123432 (RFC 3617). That RFC also points at the underlying missing capability around higher-ranked lifetime bounds on nested opaques (see Tracking Issue for impl for<'a> Trait<'a> rust-lang/rust#104288). [2]

• If what you’re hitting is the current partial-implementation limitation of use<> bounds (e.g., can’t yet write use<> in some cases), the Rust blog post on the 2024 capture rules points to tracking issue #130031 for that limitation. [3]

Sources: [1] [2] [3]

---

🌐 Web query:

rust type_alias_impl_trait tracking issue stabilization

💡 Result:

• The tracking issue for type_alias_impl_trait (“Permit impl Trait in type aliases”, RFC 2515) is rust-lang/rust #63063, opened 2019-07-28, and it is still open / unstable (nightly-only) as of the latest tracking issue state. [1]
• The feature is available on nightly behind (at least) these gates: #![feature(type_alias_impl_trait)] and (for associated types) #![feature(impl_trait_in_assoc_type)]. [1]
• Stabilization is currently blocked (the tracking issue is marked “tracking-blocked”) and its explicit “Steps” include stabilizing -Znext-solver before a stabilization PR. [1]
• The Rust Unstable Book continues to list type_alias_impl_trait as an unstable language feature and points back to #63063. [2]
• RFC text/reference: RFC 2515 defines the intended design for type Foo = impl Bar; (TAIT) and links to the same tracking issue. [3]
• Background on the blocker: the Rust project has an active effort toward stabilizing the next-generation trait solver (-Znext-solver=globally), which includes remaining “opaque types (impl Trait) changes” as part of the work. [4]

Sources: [1] rust-lang/rust issue #63063 (github.com), [2] Rust Unstable Book: type_alias_impl_trait (doc.rust-lang.org), [3] RFC 2515 (rust-lang.github.io), [4] Rust Project Goals: next solver (rust-lang.github.io)

Citations:

• 1: Tracking issue for RFC 2515, "Permit impl Trait in type aliases" rust-lang/rust#63063
• 2: https://doc.rust-lang.org/beta/unstable-book/language-features/type-alias-impl-trait.html?utm_source=openai
• 3: https://rust-lang.github.io/rfcs/2515-type_alias_impl_trait.html?utm_source=openai
• 4: https://rust-lang.github.io/rust-project-goals/2025h2/next-solver.html?utm_source=openai

---

@leynos, there are two upstream Rust tracking issues relevant to the limitations you encountered:

Primary Limitation: impl Trait in Higher-Ranked Trait Bounds

rust-lang/rust#42183 - Tracking issue for RFC 1951 (expanding impl Trait)

This is the main issue tracking the limitation preventing impl Future from being used inside higher-ranked bounds like for<'a> contexts. This affects patterns like FnOnce(...) -> impl Future.

Related issues:

• rust-lang/rust#123432 - Tracking precise capturing with use<...> for RPIT, which intersects with HRTB capture limitations
• rust-lang/rust#104288 - Higher-ranked lifetime bounds on nested opaques

Secondary Limitation: Type Alias Impl Trait (TAIT)

rust-lang/rust#63063 - Tracking issue for RFC 2515 (type_alias_impl_trait)

This feature remains unstable (nightly-only) and is currently blocked on stabilising the next-generation trait solver (-Znext-solver). It's been open since 2019 with no concrete stabilisation timeline.

Summary

Both limitations are actively tracked but have no scheduled resolution. The BoxFuture pattern you're currently using remains the standard workaround on stable Rust for expressing async closures in generic contexts with higher-ranked bounds.