Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

LocalParticipant awaits track.processor?.onPublish() unbounded inside the publish lock — any slow processor freezes publish/mute for the rest of the session

未关闭
  • 哪里不对？
#1,154 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
38/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
冷清
技术栈
dart, flutter
领域
mobile-dev

调研方向

Read lib/src/participant/local.dart at the audio and video onPublish call sites, along with lib/src/support/serial_runner.dart to understand the publish lock. Then inspect the E2EContainer harness used in #1152 and determine whether onPublish must complete before track.start() or the publish future resolves. Done means a regression test with a never-resolving processor verifies that publishing returns and a subsequent mute completes.

由索引模型根据 Issue 内容生成。

描述

Follow-up to #1151 / #1152, filed at @hiroshihorie's request in the approval review on #1152.

Summary

_publishAudioTrack runs entirely inside _publishRunner (the SerialRunner that serializes all publish/unpublish/mute/enable operations), and after the track is already fully published it does an unbounded await on third-party processor code:

TrackProcessor.onPublish is an open extension point, so the SDK is awaiting arbitrary user/plugin code — in livekit_noise_filter's case, a server round-trip — inside its most contended critical section. If that future is slow or never resolves:

  1. The track is already published and live (addTrackPublication has run, audio/video flows to remote participants).
  2. The setMicrophoneEnabled(true) / publish*Track future doesn't resolve.
  3. The held SerialRunner blocks every subsequent setMicrophoneEnabled / setCameraEnabled / setSourceEnabled / unpublish — the user cannot mute a live microphone for the rest of the session.

#1151 was one concrete trigger (the getSid() deadlock, now fixed); this issue is about the amplifier that turned it from "one hung future" into "an unmutable live mic". Any future slow onPublish reproduces the same failure.

Proposal

Detach the processor handoff from the publish critical section: the track is already fully published when onPublish runs, so treat it as asynchronous decoration — run track.processor?.onPublish(room) unawaited with errors logged (or await it after the runner block returns), instead of holding the lock on it. ~10-line diff at the two call sites, plus a regression test (fake processor whose onPublish never resolves; assert publish returns and a subsequent mute completes — same E2EContainer harness as #1152).

Alternative, if completion-before-return must be preserved: bound the await with a timeout + logged warning. Weaker — it converts "forever" into "N seconds of unmutable mic" and picks an arbitrary constant.

One semantics question I'd like your call on before opening the PR: is anything expected to rely on onPublish completing before track.start() / before the publish future resolves? If yes, the timeout variant (or detach-after-start()) is the shape.

Complementary (separate repo, happy to file there too): livekit_noise_filter.onPublish blocks on await room.getSid() just to build its context map — it could send the context immediately and update the sid when it resolves, making the plugin robust on old SDK versions as well.

I'm glad to open the PR for whichever direction you prefer.

主要语言
Dart
星标
421
派生
260
平均合并
3 天 9 小时
30 天内合并 PR
11

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

livekit/client-sdk-flutter 的其他 Issue

查看 livekit/client-sdk-flutter 的全部 Issue

相似的 Issue

更多 Dart Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。