Skip to content

fix(session): release exact claimed publish route#141

Merged
AlexanderWagnerDev merged 6 commits into
mainfrom
fix/publish-route-claim-release
Jul 18, 2026
Merged

fix(session): release exact claimed publish route#141
AlexanderWagnerDev merged 6 commits into
mainfrom
fix/publish-route-claim-release

Conversation

@AlexanderWagnerDev

@AlexanderWagnerDev AlexanderWagnerDev commented Jul 18, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Track the exact PublishRouteRegistry claim key on each connection and release that key on FCUnpublish/closeStream/play takeover
  • Avoids stale route ownership when relay_key is later pinned to a DB stream id (librtmp2-server)

Test plan

  • cargo test --lib (publish_rename / publish route unit tests)
  • Manual: publish, FCUnpublish, second connection publish same key without waiting for TCP close
  • Manual: publish with name A, set relay_key via integrator, unpublish — route A free for peer

View with Codesmith Autofix with Codesmith
Need help on this PR? Tag /codesmith with what you need. Autofix is disabled.

Summary by CodeRabbit

  • Bug Fixes
    • Publish-route claim/release is now tracked precisely, preventing stale route ownership and stale stream-cache entries when switching or evicting publish routes.
    • When switching from play to publish on the same connection, the stream role flag is updated so hosts can observe the change.
  • Tests
    • Added a unit test covering active publish-route eviction for both originally claimed and mid-publish pinned keys.
  • Chores
    • Updated local ignore settings to exclude Bug Hunter artifacts.

Pinned relay_key diverged from RTMP publish name, so FCUnpublish
left PublishRouteRegistry entries stuck until TCP close.

Co-authored-by: Cursor <cursoragent@cursor.com>
@coderabbitai

coderabbitai Bot commented Jul 18, 2026

Copy link
Copy Markdown

Review Change Stack

Warning

Review limit reached

@AlexanderWagnerDev, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 52 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: a486f4f8-1fd1-493f-b458-5abf976be460

📥 Commits

Reviewing files that changed from the base of the PR and between 332b61d and 921620f.

📒 Files selected for processing (2)
  • CHANGELOG.md
  • debian/changelog
📝 Walkthrough

Walkthrough

Conn now tracks and centrally manages publish-route claims, releases the exact claimed route during republishing or eviction, clears publishing role flags correctly, and validates cache eviction for divergent keys. Release metadata and Bug Hunter artifact ignores were also updated.

Changes

Publish route lifecycle

Layer / File(s) Summary
Claim and release helpers
src/session/conn.rs
Conn stores the claimed route and centralizes claim and release behavior, including initialization when publish routes are unavailable.
Publish and eviction integration
src/session/conn.rs
Publish handling uses the claim helper, clears stream.is_playing, and eviction releases the tracked claim while removing both claimed and pinned relay cache keys; a regression test covers this behavior.

Release metadata and local artifacts

Layer / File(s) Summary
Release metadata
Cargo.toml, CHANGELOG.md
The package version is updated to 0.4.1 and the changelog records the publish-route and stream-role fixes.
Bug Hunter artifact ignore
.gitignore
The .bug-hunter/ directory is added to the ignored paths.

Estimated code review effort: 2 (Simple) | ~10 minutes

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately summarizes the main session route cleanup change and is concise.
Docstring Coverage ✅ Passed Docstring coverage is 85.71% which is sufficient. The required threshold is 80.00%.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/publish-route-claim-release

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@qodo-code-review

Copy link
Copy Markdown

PR Summary by Qodo

Fix publish route claim tracking to release the exact claimed key

🐞 Bug fix 🕐 20-40 Minutes

Grey Divider

AI Description

• Track the exact PublishRouteRegistry key claimed per connection.
• Release the claimed key on FCUnpublish, deleteStream, play takeover, and stream replacement.
• Prevent stale publish-route ownership when relay_key diverges from the RTMP publish name.
Diagram

graph TD
  C[Client] --> P["publish"] --> S["Conn (session)"] --> K["claim_publish_route()"] --> R["PublishRouteRegistry"]
  C --> U["FCUnpublish / play"] --> S --> L["release_claimed_publish_route()"] --> R
  S --> T["relay_route_key()"] --> K
Loading
High-Level Assessment

The following are alternative approaches to this PR:

1. RAII route-claim guard (Drop releases)
  • ➕ Eliminates reliance on remembering to call release paths (Drop handles teardown)
  • ➕ Makes ownership/release semantics explicit and harder to regress
  • ➖ More invasive refactor across publish lifecycle and stream transitions
  • ➖ Must carefully handle rename semantics and early-return error paths
2. Registry tracks conn_id→claimed_key mapping
  • ➕ Release can be done by conn_id without the caller holding the key
  • ➕ Centralizes ownership bookkeeping in one place
  • ➖ Adds state and complexity to PublishRouteRegistry API
  • ➖ Harder to reason about correctness if multiple keys per conn are ever introduced

Recommendation: Current approach is a good, minimal fix: storing the exact claimed key on Conn aligns claim/release behavior and addresses relay_key divergence without broad API changes. The RAII guard is worth considering if route-claim lifecycle grows more complex or if regressions recur, but it’s likely overkill for this targeted bug.

Files changed (1) +41 / -11

Bug fix (1) +41 / -11
conn.rsTrack and release exact publish-route claim per connection +41/-11

Track and release exact publish-route claim per connection

• Adds per-connection tracking of the exact publish-route key claimed in PublishRouteRegistry. Introduces helper methods to claim/release the tracked key and wires them into publish rename and publish teardown paths to avoid stale route ownership when relay_key changes later.

src/session/conn.rs

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🧹 Nitpick comments (1)
src/session/conn.rs (1)

346-351: 🎯 Functional Correctness | 🔵 Trivial | 💤 Low value

Avoid rebuilding claimed_publish_route on the no-op path. When prev == 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

📥 Commits

Reviewing files that changed from the base of the PR and between 8aec698 and 8c5c196.

📒 Files selected for processing (2)
  • .gitignore
  • src/session/conn.rs

@qodo-code-review

qodo-code-review Bot commented Jul 18, 2026

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 🔗 Cross-repo conflicts (1) 📜 Skill insights (0)

Context used
✅ Compliance rules (platform): 11 rules
✅ Cross-repo context
  Explored: repo: OpenRTMP/librtmp2-server (sha: a8bb8752)

Grey Divider


Action required

1. Freed route keeps stale cache ✓ Resolved 🐞 Bug ≡ Correctness
Description
evict_active_publish_route() releases claimed_publish_route but queues pending_cache_evictions
using the current relay_route_key(), so if relay_key changed mid-publish the freed route’s
stream_cache entry can remain and be replayed to later sessions. This is a behavioral regression:
after this PR the route can be re-claimed immediately, but the old cached init frames/keyframe for
that route may still be served.
Code

src/session/conn.rs[R312-317]

+        self.release_claimed_publish_route();
        let route_key = self.relay_route_key();
        if !route_key.is_empty() {
-            self.release_publish_route(&route_key);
            self.pending_cache_evictions
                .push((self.app.clone(), route_key));
        }
Relevance

⭐⭐⭐ High

Team previously accepted fixes preventing stale stream_cache replay/eviction mismatches (e.g., clear
stale cached init data).

PR-#99
PR-#48
PR-#127

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The connection now releases the claimed publish-route key independently of the cache-eviction key;
because the server’s stream cache eviction mechanism is driven solely by pending_cache_evictions
and cache replay uses conn.relay_route_key(), a divergence between claimed_publish_route and
relay_route_key() can leave stale cache entries for a route that has been freed for reuse.

src/session/conn.rs[282-291]
src/session/conn.rs[297-318]
src/server/mod.rs[617-689]
src/server/mod.rs[1127-1176]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`Conn::evict_active_publish_route()` now releases the exact claimed publish-route key (`claimed_publish_route`) but still queues stream-cache eviction based on `relay_route_key()`. When `relay_key` diverges from the original claimed route during a publish session, unpublish/closeStream/play takeover can free the old route while leaving its `stream_cache` entry intact.

## Issue Context
- `relay_route_key()` prefers `relay_key` over the RTMP stream name, so changing `relay_key` mid-session changes the stream-cache keying.
- The server only removes cache entries for keys drained from `Conn.pending_cache_evictions`; remaining `stream_cache` entries are replayed to new players based on `(app, conn.relay_route_key())`.

## Fix Focus Areas
- src/session/conn.rs[297-318]

### Suggested change
In `evict_active_publish_route()`, capture the claimed key before releasing it and enqueue eviction for that claimed key (and optionally also for the current `relay_route_key()` if different), e.g.:
- `let claimed = self.claimed_publish_route.clone();`
- `self.release_claimed_publish_route();`
- `if let Some(key) = claimed { if !key.is_empty() { self.pending_cache_evictions.push((self.app.clone(), key)); } }`
- Consider also evicting `relay_route_key()` if it differs, to cover cache entries created after `relay_key` changed.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

2. Changelog links not updated ✓ Resolved 🐞 Bug ⚙ Maintainability
Description
A new ## [0.4.1] section was added, but the reference-style link definitions at the bottom were
not updated, so [0.4.1] won’t resolve to a compare URL and [Unreleased] still compares from
v0.4.0 instead of v0.4.1. This breaks the intended Keep-a-Changelog navigation/compare links for
the new release.
Code

CHANGELOG.md[16]

+## [0.4.1] — 2026-07-18
Relevance

⭐⭐⭐ High

Release PRs update changelog compare links when adding new version sections (see PR #79).

PR-#79

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The new release header uses reference-style [0.4.1], but the reference definitions section still
points Unreleased at v0.4.0...HEAD and has no [0.4.1] entry, so the new header cannot resolve to
a link target and Unreleased compare base is outdated.

CHANGELOG.md[16-17]
CHANGELOG.md[323-324]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`CHANGELOG.md` introduced a new reference-style heading `## [0.4.1]`, but the link reference block at the bottom still only defines `[Unreleased]` (from `v0.4.0`) and `[0.4.0]`. As a result, the new release heading won’t link properly and the Unreleased compare base is stale.

### Issue Context
The changelog uses reference-style links (`[0.4.0]: ...`) for GitHub compare navigation. Adding a new release should (1) add a `[0.4.1]: ...` compare link and (2) advance `[Unreleased]` to compare from `v0.4.1`.

### Fix Focus Areas
- CHANGELOG.md[16-17]
- CHANGELOG.md[323-324]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


3. Debian package version stale 🐞 Bug ⚙ Maintainability
Description
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.
Code

Cargo.toml[3]

+version = "0.4.1"
Relevance

⭐⭐⭐ High

Debian packaging is actively maintained; debian/changelog updated in release-related work (PR #108,
#106).

PR-#108
PR-#106

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
Cargo.toml shows the crate release version is now 0.4.1, while debian/changelog’s most recent entry
still identifies the package as 0.4.0-1, demonstrating the mismatch.

Cargo.toml[1-4]
debian/changelog[1-2]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### 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


4. Server lockfile blocks 0.4.1 🔗 Cross-repo conflict ☼ Reliability
Description
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.
Code

Cargo.toml[3]

+version = "0.4.1"
Relevance

⭐⭐ Medium

No repo history of accepting cross-repo lockfile coordination requests; may be seen as out-of-scope.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The PR bumps librtmp2 to 0.4.1 and the changelog states fixes aimed at host integrators that pin
relay_key after publish. In librtmp2-server, that exact pinning happens (`conn.relay_key =
entry.stream_id.clone()`), but the server repo is currently locked to librtmp2 0.4.0 in Cargo.lock
and its CI builds/tests use the lockfile, so it will not consume 0.4.1 until Cargo.lock is
regenerated (which their workflow does via cargo generate-lockfile).

Cargo.toml[1-6]
CHANGELOG.md[16-37]
External repo: OpenRTMP/librtmp2-server, src/server.rs [238-270]
External repo: OpenRTMP/librtmp2-server, Cargo.toml [17-20]
External repo: OpenRTMP/librtmp2-server, Cargo.lock [868-873]
External repo: OpenRTMP/librtmp2-server, .github/workflows/tests.yml [32-37]
External repo: OpenRTMP/librtmp2-server, .github/workflows/update-cargo-lock.yml [26-28]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## 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



Informational

5. Debian changelog overclaims release ✓ Resolved 🐞 Bug ⚙ Maintainability ⭐ New
Description
The new 0.4.1-1 debian/changelog entry says the connection releases the claimed publish-route key
and also the current relay route key if it was later pinned, but the implementation only releases
the originally claimed PublishRouteRegistry key and separately evicts stream-cache keys for both.
This can mislead packagers/integrators about the route-ownership semantics vs cache-eviction
behavior.
Code

debian/changelog[R3-6]

+  * Track the exact publish-route key claimed per connection and release
+    that same key (and the current relay route key, if pinned to a
+    different value afterward) on FCUnpublish/closeStream/play takeover,
+    fixing stale route ownership and stale stream_cache replay.
Relevance

⭐⭐⭐ High

Team fixes misleading release/docs claims; accepted changelog wording correction (PR #94) and README
misleading claim fix (PR #28).

PR-#94
PR-#28
PR-#106

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The Debian changelog text claims both keys are “released”, while the session code releases only
claimed_publish_route via routes.release(...) and uses the current relay_route_key() only to
enqueue cache evictions.

debian/changelog[1-9]
src/session/conn.rs[303-336]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`debian/changelog` currently states that on teardown the connection releases both the originally claimed publish-route key and the (possibly later pinned) current relay route key. In the code, only the originally claimed key is released from `PublishRouteRegistry`; the “current relay route key” is only used for `stream_cache` eviction.

## Issue Context
This is a release-notes correctness issue: route-registry ownership release and stream-cache eviction are separate operations. The changelog should accurately reflect that distinction.

## Fix Focus Areas
- debian/changelog[3-6]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


6. Unused route-release helper ✓ Resolved 🐞 Bug ⚙ Maintainability
Description
release_publish_route() appears to have no remaining call sites after switching to
claim_publish_route()/release_claimed_publish_route(), leaving dead code that can mislead future
refactors and trigger dead_code warnings. The active teardown paths now call
release_claimed_publish_route() instead.
Code

src/session/conn.rs[R322-328]

        if let Some(routes) = self.publish_routes.as_ref() {
            routes.release(self.conn_id, &self.app, stream);
        }
+        if self.claimed_publish_route.as_deref() == Some(stream) {
+            self.claimed_publish_route = None;
+        }
+    }
Relevance

⭐⭐⭐ High

Repo regularly accepts cleanup to avoid misleading/unused code and warnings (e.g., removing
redundant unused imports/helpers).

PR-#64
PR-#127

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
After the change, teardown uses release_claimed_publish_route() and publish rename flows use
claim_publish_route(); release_publish_route() remains defined but is not referenced by these
updated paths.

src/session/conn.rs[297-353]
src/session/conn.rs[1276-1301]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`Conn::release_publish_route()` is no longer used after this refactor (teardown now uses `release_claimed_publish_route()`, and publish rename now goes through `claim_publish_route()`), so the leftover helper is dead code.

## Issue Context
Keeping an unused route-release helper around is confusing because it suggests there are still call paths releasing arbitrary stream keys, when the code is now centered around the tracked `claimed_publish_route`.

## Fix Focus Areas
- src/session/conn.rs[321-353]

### Suggested change
- Remove `release_publish_route()` if it truly has no remaining uses.
- If you still need a “release by explicit key” helper, reintroduce a call site (and document when it should be used) or make it a thin wrapper around the claimed-key logic to avoid divergence.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Previous review results

Review updated until commit 921620f

Results up to commit 8c5c196


🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)


Action required
1. Freed route keeps stale cache ✓ Resolved 🐞 Bug ≡ Correctness
Description
evict_active_publish_route() releases claimed_publish_route but queues pending_cache_evictions
using the current relay_route_key(), so if relay_key changed mid-publish the freed route’s
stream_cache entry can remain and be replayed to later sessions. This is a behavioral regression:
after this PR the route can be re-claimed immediately, but the old cached init frames/keyframe for
that route may still be served.
Code

src/session/conn.rs[R312-317]

+        self.release_claimed_publish_route();
        let route_key = self.relay_route_key();
        if !route_key.is_empty() {
-            self.release_publish_route(&route_key);
            self.pending_cache_evictions
                .push((self.app.clone(), route_key));
        }
Relevance

⭐⭐⭐ High

Team previously accepted fixes preventing stale stream_cache replay/eviction mismatches (e.g., clear
stale cached init data).

PR-#99
PR-#48
PR-#127

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The connection now releases the claimed publish-route key independently of the cache-eviction key;
because the server’s stream cache eviction mechanism is driven solely by pending_cache_evictions
and cache replay uses conn.relay_route_key(), a divergence between claimed_publish_route and
relay_route_key() can leave stale cache entries for a route that has been freed for reuse.

src/session/conn.rs[282-291]
src/session/conn.rs[297-318]
src/server/mod.rs[617-689]
src/server/mod.rs[1127-1176]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`Conn::evict_active_publish_route()` now releases the exact claimed publish-route key (`claimed_publish_route`) but still queues stream-cache eviction based on `relay_route_key()`. When `relay_key` diverges from the original claimed route during a publish session, unpublish/closeStream/play takeover can free the old route while leaving its `stream_cache` entry intact.

## Issue Context
- `relay_route_key()` prefers `relay_key` over the RTMP stream name, so changing `relay_key` mid-session changes the stream-cache keying.
- The server only removes cache entries for keys drained from `Conn.pending_cache_evictions`; remaining `stream_cache` entries are replayed to new players based on `(app, conn.relay_route_key())`.

## Fix Focus Areas
- src/session/conn.rs[297-318]

### Suggested change
In `evict_active_publish_route()`, capture the claimed key before releasing it and enqueue eviction for that claimed key (and optionally also for the current `relay_route_key()` if different), e.g.:
- `let claimed = self.claimed_publish_route.clone();`
- `self.release_claimed_publish_route();`
- `if let Some(key) = claimed { if !key.is_empty() { self.pending_cache_evictions.push((self.app.clone(), key)); } }`
- Consider also evicting `relay_route_key()` if it differs, to cover cache entries created after `relay_key` changed.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Informational
2. Unused route-release helper ✓ Resolved 🐞 Bug ⚙ Maintainability
Description
release_publish_route() appears to have no remaining call sites after switching to
claim_publish_route()/release_claimed_publish_route(), leaving dead code that can mislead future
refactors and trigger dead_code warnings. The active teardown paths now call
release_claimed_publish_route() instead.
Code

src/session/conn.rs[R322-328]

        if let Some(routes) = self.publish_routes.as_ref() {
            routes.release(self.conn_id, &self.app, stream);
        }
+        if self.claimed_publish_route.as_deref() == Some(stream) {
+            self.claimed_publish_route = None;
+        }
+    }
Relevance

⭐⭐⭐ High

Repo regularly accepts cleanup to avoid misleading/unused code and warnings (e.g., removing
redundant unused imports/helpers).

PR-#64
PR-#127

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
After the change, teardown uses release_claimed_publish_route() and publish rename flows use
claim_publish_route(); release_publish_route() remains defined but is not referenced by these
updated paths.

src/session/conn.rs[297-353]
src/session/conn.rs[1276-1301]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`Conn::release_publish_route()` is no longer used after this refactor (teardown now uses `release_claimed_publish_route()`, and publish rename now goes through `claim_publish_route()`), so the leftover helper is dead code.

## Issue Context
Keeping an unused route-release helper around is confusing because it suggests there are still call paths releasing arbitrary stream keys, when the code is now centered around the tracked `claimed_publish_route`.

## Fix Focus Areas
- src/session/conn.rs[321-353]

### Suggested change
- Remove `release_publish_route()` if it truly has no remaining uses.
- If you still need a “release by explicit key” helper, reintroduce a call site (and document when it should be used) or make it a thin wrapper around the claimed-key logic to avoid divergence.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Results up to commit 332b61d


🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (1) 📜 Skill insights (0)


Remediation recommended
1. Changelog links not updated ✓ Resolved 🐞 Bug ⚙ Maintainability
Description
A new ## [0.4.1] section was added, but the reference-style link definitions at the bottom were
not updated, so [0.4.1] won’t resolve to a compare URL and [Unreleased] still compares from
v0.4.0 instead of v0.4.1. This breaks the intended Keep-a-Changelog navigation/compare links for
the new release.
Code

CHANGELOG.md[16]

+## [0.4.1] — 2026-07-18
Relevance

⭐⭐⭐ High

Release PRs update changelog compare links when adding new version sections (see PR #79).

PR-#79

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The new release header uses reference-style [0.4.1], but the reference definitions section still
points Unreleased at v0.4.0...HEAD and has no [0.4.1] entry, so the new header cannot resolve to
a link target and Unreleased compare base is outdated.

CHANGELOG.md[16-17]
CHANGELOG.md[323-324]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`CHANGELOG.md` introduced a new reference-style heading `## [0.4.1]`, but the link reference block at the bottom still only defines `[Unreleased]` (from `v0.4.0`) and `[0.4.0]`. As a result, the new release heading won’t link properly and the Unreleased compare base is stale.

### Issue Context
The changelog uses reference-style links (`[0.4.0]: ...`) for GitHub compare navigation. Adding a new release should (1) add a `[0.4.1]: ...` compare link and (2) advance `[Unreleased]` to compare from `v0.4.1`.

### Fix Focus Areas
- CHANGELOG.md[16-17]
- CHANGELOG.md[323-324]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. Debian package version stale 🐞 Bug ⚙ Maintainability
Description
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.
Code

Cargo.toml[3]

+version = "0.4.1"
Relevance

⭐⭐⭐ High

Debian packaging is actively maintained; debian/changelog updated in release-related work (PR #108,
#106).

PR-#108
PR-#106

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
Cargo.toml shows the crate release version is now 0.4.1, while debian/changelog’s most recent entry
still identifies the package as 0.4.0-1, demonstrating the mismatch.

Cargo.toml[1-4]
debian/changelog[1-2]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### 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


3. Server lockfile blocks 0.4.1 🔗 Cross-repo conflict ☼ Reliability
Description
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.
Code

Cargo.toml[3]

+version = "0.4.1"
Relevance

⭐⭐ Medium

No repo history of accepting cross-repo lockfile coordination requests; may be seen as out-of-scope.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The PR bumps librtmp2 to 0.4.1 and the changelog states fixes aimed at host integrators that pin
relay_key after publish. In librtmp2-server, that exact pinning happens (`conn.relay_key =
entry.stream_id.clone()`), but the server repo is currently locked to librtmp2 0.4.0 in Cargo.lock
and its CI builds/tests use the lockfile, so it will not consume 0.4.1 until Cargo.lock is
regenerated (which their workflow does via cargo generate-lockfile).

Cargo.toml[1-6]
CHANGELOG.md[16-37]
External repo: OpenRTMP/librtmp2-server, src/server.rs [238-270]
External repo: OpenRTMP/librtmp2-server, Cargo.toml [17-20]
External repo: OpenRTMP/librtmp2-server, Cargo.lock [868-873]
External repo: OpenRTMP/librtmp2-server, .github/workflows/tests.yml [32-37]
External repo: OpenRTMP/librtmp2-server, .github/workflows/update-cargo-lock.yml [26-28]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## 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


Qodo Logo

Comment thread src/session/conn.rs
Comment thread src/session/conn.rs Outdated
- 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.
@qodo-code-review

Copy link
Copy Markdown

Code review by qodo was updated up to the latest commit 22b7c89

@AlexanderWagnerDev

Copy link
Copy Markdown
Contributor Author

@codex review

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

💡 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".

Comment thread src/session/conn.rs Outdated
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.
@qodo-code-review

Copy link
Copy Markdown

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.
Comment thread CHANGELOG.md
Comment thread Cargo.toml
[package]
name = "librtmp2"
version = "0.4.0"
version = "0.4.1"

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Remediation recommended

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

Comment thread Cargo.toml
[package]
name = "librtmp2"
version = "0.4.0"
version = "0.4.1"

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Remediation recommended

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

@qodo-code-review

Copy link
Copy Markdown

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.
Comment thread debian/changelog Outdated
@qodo-code-review

Copy link
Copy Markdown

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.
@qodo-code-review

Copy link
Copy Markdown

Code review by qodo was updated up to the latest commit 921620f

@AlexanderWagnerDev
AlexanderWagnerDev merged commit bf2ea16 into main Jul 18, 2026
32 checks passed
@AlexanderWagnerDev
AlexanderWagnerDev deleted the fix/publish-route-claim-release branch July 18, 2026 16:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants