fix(session): release exact claimed publish route#141
Conversation
Pinned relay_key diverged from RTMP publish name, so FCUnpublish left PublishRouteRegistry entries stuck until TCP close. Co-authored-by: Cursor <cursoragent@cursor.com>
|
Warning Review limit reached
Next review available in: 52 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthrough
ChangesPublish route lifecycle
Release metadata and local artifacts
Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
PR Summary by QodoFix publish route claim tracking to release the exact claimed key
AI Description
Diagram
High-Level Assessment
Files changed (1)
|
There was a problem hiding this comment.
🧹 Nitpick comments (1)
src/session/conn.rs (1)
346-351: 🎯 Functional Correctness | 🔵 Trivial | 💤 Low valueAvoid rebuilding
claimed_publish_routeon the no-op path. Whenprev == stream, keep the existing route string instead of dropping and recreating it.🤖 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 `@src/session/conn.rs` around lines 346 - 351, Update the claimed publish route handling around claimed_publish_route so the existing string is preserved when prev == stream. Only release and replace the route when the previous value differs, while still assigning the new stream string when no prior route exists.
🤖 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.
Nitpick comments:
In `@src/session/conn.rs`:
- Around line 346-351: Update the claimed publish route handling around
claimed_publish_route so the existing string is preserved when prev == stream.
Only release and replace the route when the previous value differs, while still
assigning the new stream string when no prior route exists.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 1875f0b3-b7e5-4057-8921-cd3d0073e8fa
📒 Files selected for processing (2)
.gitignoresrc/session/conn.rs
Code Review by Qodo
Context used✅ Compliance rules (platform):
11 rules✅ Cross-repo context Explored:
repo: OpenRTMP/librtmp2-server (sha: a8bb8752) 1.
|
- evict_active_publish_route() now queues cache eviction for the exact claimed_publish_route key instead of relay_route_key(), so a mid-session relay_key change can't leave a stale stream_cache entry behind for a route that was just freed. - Remove the dead release_publish_route() helper superseded by release_claimed_publish_route(). - Avoid rebuilding claimed_publish_route on the no-op reclaim path. - publish() now clears is_playing (mirroring what play() already does for is_publishing) so a play->publish switch on the same connection is detected by hosts polling stream role flags. Addresses CodeRabbit/Qodo review findings on PR #141.
|
Code review by qodo was updated up to the latest commit 22b7c89 |
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 22b7c895c8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
evict_active_publish_route() evicted only the route key claimed at publish time. Cached RelayFrames are keyed by relay_route_key() live at frame-queue time (RelayFrame::stream_name), so if an integrator pins relay_key after the route was already claimed, subsequent frames get cached under the new key while eviction only cleared the old one -- leaving a stale cache entry behind under the new key. Evict both the claimed key and the current relay_route_key() (when they differ) to cover cache entries created under either. Addresses Codex review finding on PR #141.
|
Code review by qodo was updated up to the latest commit d76fe2d |
Cut the accumulated Unreleased changelog entries into 0.4.1, including this branch's publish-route-claim fixes. No public API/ABI surface changed (extern "C" functions in src/lib.rs untouched); the abi-baseline.sh comparison tooling isn't available in this environment to run the full compare, but all changes here are confined to private session internals.
| [package] | ||
| name = "librtmp2" | ||
| version = "0.4.0" | ||
| version = "0.4.1" |
There was a problem hiding this comment.
2. Debian package version stale 🐞 Bug ⚙ Maintainability
The crate version was bumped to 0.4.1, but debian/changelog still declares the top package entry as 0.4.0-1. If Debian packaging/release artifacts are expected to track the crate release, this will publish/build Debian metadata for the wrong version.
Agent Prompt
### Issue description
Cargo.toml now declares crate version `0.4.1`, but the Debian packaging changelog still has `librtmp2 (0.4.0-1)` as the latest entry. If the Debian package release is meant to correspond to the crate release, this should be updated to `0.4.1-1` (or whatever Debian revision is intended).
### Issue Context
Debian package versioning is driven by `debian/changelog`. Keeping it aligned with the crate version avoids publishing a Debian package with stale version metadata for a `0.4.1` crate release.
### Fix Focus Areas
- Cargo.toml[1-4]
- debian/changelog[1-15]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| [package] | ||
| name = "librtmp2" | ||
| version = "0.4.0" | ||
| version = "0.4.1" |
There was a problem hiding this comment.
3. Server lockfile blocks 0.4.1 🔗 Cross-repo conflict ☼ Reliability
This PR releases librtmp2 0.4.1 and documents fixes that directly target librtmp2-server’s integration pattern (pinning Conn.relay_key after publish), but librtmp2-server’s Cargo.lock pins librtmp2 to 0.4.0 so CI/deployments will keep running the pre-fix behavior until the lockfile is updated. Coordinate a follow-up in librtmp2-server to refresh Cargo.lock to 0.4.1 and run its test/e2e workflows.
Agent Prompt
## Issue description
`librtmp2` is being released as 0.4.1 and the changelog explicitly calls out fixes for the `librtmp2-server` integration (relay_key pinning after publish). However, `librtmp2-server` is pinned to `librtmp2` 0.4.0 in `Cargo.lock`, and its CI builds/tests use the lockfile, so it won’t pick up 0.4.1 until the lockfile is refreshed.
## Issue Context
- `librtmp2-server` sets `conn.relay_key` to a DB stream id after it detects publishing/playing; this is the integration pattern the 0.4.1 changelog fix references.
- `librtmp2-server` has an `update-cargo-lock.yml` workflow that runs `cargo generate-lockfile` and commits changes, but it must be triggered after the 0.4.1 publish to actually move from 0.4.0 to 0.4.1.
## Fix Focus Areas
- /cross_repos/librtmp2-server/Cargo.lock[868-873]
- /cross_repos/librtmp2-server/.github/workflows/update-cargo-lock.yml[26-28]
- /cross_repos/librtmp2-server/.github/workflows/tests.yml[32-37]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
|
Code review by qodo was updated up to the latest commit 332b61d |
- CHANGELOG.md: add the [0.4.1] reference-style compare link and advance [Unreleased] to compare from v0.4.1 instead of v0.4.0. - debian/changelog: add a 0.4.1-1 entry mirroring the crate changelog, keeping Debian packaging metadata in sync with Cargo.toml. Addresses Qodo review findings on PR #141.
|
Code review by qodo was updated up to the latest commit 5dd646a |
The 0.4.1-1 entry conflated releasing the claimed key from PublishRouteRegistry with evicting stream_cache entries for both keys -- only the former is a registry release; the current relay route key is only used to enqueue a cache eviction, never released from the registry. Split into two accurate sentences. Addresses a Qodo review finding on PR #141.
|
Code review by qodo was updated up to the latest commit 921620f |
Summary
PublishRouteRegistryclaim key on each connection and release that key on FCUnpublish/closeStream/play takeoverrelay_keyis later pinned to a DB stream id (librtmp2-server)Test plan
cargo test --lib(publish_rename / publish route unit tests)Need help on this PR? Tag
/codesmithwith what you need. Autofix is disabled.Summary by CodeRabbit