Anarlog 的 Vexa v0.12.18 Google Meet 行为矩阵准入/运行时分类器与生命周期终止原因全解【免费下载链接】anarlogOpen source Granola AI Alternative项目地址: https://gitcode.com/GitHub_Trending/hy/anarlog导读本文以 Anarlog 企业版 Google Meet Workerenterprise/google-meet-worker仓库中固定版本 Vexav0.12.18的行为矩阵behavior matrix文档为核心系统拆解其准入admission与运行时runtime状态分类器、14 个生命周期lifecycle场景及其供应商无关的终止原因terminal reason语义。读完本文你将掌握 Google Meet 会议机器人在加入→被拒→等待→入会→被移除→断网→会议结束等全链路状态下的判定逻辑、宽限期grace参数、可重试语义以及这些行为是如何通过可回放replayable的 JSON 快照进行自动化验证的。一、矩阵文档的定位与设计初衷1.1 Pinned Reference固定版本的行为契约MATRIX.md 开头明确了这份矩阵的基准Pinned reference: Vexav0.12.18, commit1b62993e7e97c6ee04a5dcb116f7749ec74169df.Vexa 是一个开源的会议录制/转录机器人项目Anarlog 在 enterprise Google Meet Worker 中采纳了其准入与运行时分类器的行为并将其以归一化normalized快照的形式固化为可回放的 fixture。关键点在于文档自己强调的These fixtures are replayable snapshots of normalized Anarlog admission/runtime classifiers. They do not require Vexa internals at test time.也就是说测试时完全不依赖 Vexa 的内部实现只需要这些归一化后的快照数据即可驱动 Anarlog 自己的分类器。这种做法把第三方行为沉淀为可复现的测试资产避免测试因上游变化而漂移。从实现上看分类器代码在文件头也明确标注了来源见 admission.rs 与 runtime.rs 首行注释Adapted for Anarlog from Vexa v0.12.18并在 THIRD_PARTY_NOTICES.md 与 VEXA-LICENSE 中保留了完整的第三方版权与许可说明。1.2 fixture 的目录结构fixture 快照被组织在 fixtures/vexa-v0.12.18 下admission/准入阶段的页面状态快照6 个runtime/入会并开始捕获后的页面状态快照10 个scenarios.json跨越多个快照、按时间轴回放的生命周期场景14 个MATRIX.md行为矩阵文档本身。每个快照 JSON 都是一个页面探针probe输出的归一化结果例如 admission/host-denied.json{ id: host-denied, kind: admission, elapsed_ms: 0, snapshot: { waiting_room_visible: true, consent_prompt_visible: false, explicit_denial_indicator: denied your request, ambiguous_error_indicator: null, visible_recaptcha_challenge: false, participant_tile_labels: [], self_name_nodes: 0, visible_admission_controls: 0 }, expected: { outcome: rejected, reason: host_denied, indicator: denied your request } }顶层expected字段声明了该快照应当被分类出的结果测试直接拿它做断言基准。二、行为矩阵总览16 个 fixture 快照2.1 准入阶段admission6 个FixtureVexa 模块Anarlog outcomeTerminal reasonRetryableadmission/host-denied.jsonjoin/src/googlemeet/admission.tsRejected HostDeniedadmission_deniednoadmission/waiting-room.jsonjoin/src/googlemeet/admission.tsWaitingForAdmission——admission/admitted.jsonjoin/src/googlemeet/join.tsAdmitted——admission/captcha-unsolved.jsonjoin/src/googlemeet/admission.tsRejected CaptchaUnsolvedauthentication_failednoadmission/error-page.jsonjoin/src/googlemeet/admission.tsRejected ErrorPageprovider_errornoadmission/consent.jsonjoin/src/googlemeet/admission.tsConsentRequired——准入阶段覆盖了三种终态拒绝HostDenied / CaptchaUnsolved / ErrorPage与三种非终态等待WaitingForAdmission / Admitted / ConsentRequired。其中终态拒绝分别映射为admission_denied、authentication_failed、provider_error且全部不可重试——它们代表 Google 侧的确定性拒绝重试没有意义。2.2 运行时阶段runtime10 个FixtureVexa 模块Anarlog outcomeTerminal reasonRetryableruntime/removed.jsonjoin/src/googlemeet/removal.tsRemovedremoved_from_meetingnoruntime/meeting-ended.jsonjoin/src/googlemeet/removal.tsMeetingEndedmeeting_endednoruntime/network-lost.jsonjoin/src/googlemeet/removal.tsNetworkLost after gracenetwork_lostyesruntime/active.jsongmeet-capture/src/gmeet-capture.tsActive——runtime/silence.jsongmeet-capture/src/pcm-capture.tsActive (no tiles besides bot)no_one_joinedafter graceyesruntime/nobody-joined.jsongmeet-capture/src/pcm-capture.tsActive until empty-room graceno_one_joinedyesruntime/overlapping-speakers.jsongmeet-capture/src/gmeet-speakers.tsActive with two named tiles——runtime/speaker-renamed.jsongmeet-capture/src/gmeet-speakers.tsActive with renamed tile——runtime/unresolved-speaker.jsongmeet-capture/src/gmeet-speakers.tsActive with chrome chrome-ui tile——runtime/long-duration.jsongmeet-capture/src/gmeet-capture.tsActive after two hours——注意runtime/silence.json的含义机器人已入会有 self tile但没有任何其他参会者画面此时短时仍判Active只有当空场宽限期empty-room grace耗尽后才转换为no_one_joined且可重试——网络瞬断或无人入会属于环境问题重新调度会话是合理的。三、准入分类器AdmissionClassifier源码级解析行为矩阵中的 6 个 admission fixture 正是 admission.rs 中AdmissionClassifier::classify的输入输出契约。3.1 快照结构AdmissionSnapshotAdmissionSnapshotadmission.rs包含 8 个字段全部来自浏览器页面探针字段类型含义waiting_room_visiblebool等待室waiting room是否可见consent_prompt_visiblebool同意/授权弹窗是否可见explicit_denial_indicatorOptionString明确的拒绝文案如 denied your requestambiguous_error_indicatorOptionString模糊错误文案如 Try againvisible_recaptcha_challengebool是否出现 reCAPTCHA 人机验证participant_tile_labelsVecString参与者画面上的名字标签列表self_name_nodesusize页面上自身名字节点数量visible_admission_controlsusize可见的准入控制组件数量其中real_participant_tiles()会过滤掉 Google Meet 的 visual_effects / Backgrounds and effects 这类装饰性标签避免把特效预览误判为真实参会者——这一点有专门单测effects_preview_is_not_a_real_participant验证admission.rs 测试模块。3.2 分类决策顺序classifyadmission.rs按确定性优先级依次判定一旦命中即返回显式拒绝 一切只要explicit_denial_indicator存在直接Rejected(HostDenied)。即使同时出现 reCAPTCHA 与等待室副本也照样以拒绝为准单测explicit_host_denial_wins_over_captcha_and_stale_waiting_copy覆盖。模糊错误 reCAPTCHA进入验证码宽限期DEFAULT_CAPTCHA_GRACE 120s。宽限期内返回CaptchaChallenge { remaining }持续等待超过 120 秒仍未解决则Rejected(CaptchaUnsolved)。单测captcha_suppression_expires_instead_of_polling_forever验证了宽限到期前 1 秒仍在等待、到期即拒绝的边界。模糊错误无验证码Rejected(ErrorPage)对应页面渲染出错。等待室可见WaitingForAdmission机器人滞留等待室。同意弹窗可见ConsentRequired需要用户/管理员授权。存在准入信号真实参与者画面、自身名字节点、准入控件任一非零Admitted。以上皆非Unknown等待下一次探针。单测waiting_and_consent_guards_suppress_lobby_false_positives还保证了即使等待室/同意弹窗场景下出现了准入控件或参与者标签也不会被误判为Admitted。3.3 fixture 与宽限期的对应admission/captcha-unsolved.json的elapsed_ms为120000即 120 秒正好等于DEFAULT_CAPTCHA_GRACE——fixture 通过elapsed_ms字段模拟验证码已超时从而让测试在不真实等待 2 分钟的情况下验证 CaptchaUnsolved 的终态。四、运行时分类器RuntimeClassifier源码级解析运行时阶段的 10 个 fixture 对应 runtime.rs 中的RuntimeClassifier::classifyruntime.rs。4.1 快照结构与判定优先级RuntimeSnapshot结构更简单removal_indicator、meeting_ended_indicator、connection_problem_indicator三个 Option 文案 participant_tile_labels/self_name_nodes/visible_meeting_controls三个活跃信号。判定顺序为被移除 会议结束 断网removal_indicator如 you were removed优先于meeting_ended_indicatormeeting ended再优先于connection_problem_indicatorreconnecting。单测explicit_removal_wins_over_ended_and_connection_copy验证了这一优先级。断网宽限期DEFAULT_CONNECTION_GRACE 30s。出现connection_problem_indicator后 30 秒内返回ConnectionInterrupted { remaining }网络恢复则回到 Active超过 30 秒才升级为NetworkLost。单测transient_reconnection_has_a_bounded_grace_period精确验证了30 秒整时切换为 NetworkLost。活跃信号判定与准入类似self_name_nodes/visible_meeting_controls/ 非装饰性参与者标签任一存在即Active。未知状态不能无限轮询DEFAULT_RUNTIME_UNKNOWN_GRACE 30s连续 30 秒没有任何信号则进入StateLost单测unknown_runtime_state_cannot_poll_forever覆盖。4.2 两个关键 fixture 的对照runtime/network-lost.jsonelapsed_ms 3000030 秒connection_problem_indicator reconnecting正好越过连接宽限期得出NetworkLost。这与DEFAULT_CONNECTION_GRACE一一对应。runtime/silence.jsonelapsed_ms 0只有自身 tileself_name_nodes: 1没有其他人——立即判Active空场宽限期在生命周期层处理见下一节。五、生命周期场景scenarios.json 与 14 个终止原因scenarios.json 把上述快照按时间轴串成多步场景通过 lifecycle.rs 的WorkerLifecycle状态机回放最终断言供应商无关的终止原因。矩阵文档给出的额外场景表ScenarioTerminal reasonRetryableeveryone-left-after-participantseveryone_leftnosilence-then-nobody-joinedno_one_joinedyeshost-ended-after-long-capturemeeting_endednocaptcha-unsolvedauthentication_failednoerror-page-before-joinprovider_errornostopped-by-requeststopped_by_requestno这 6 个场景是组合行为而非新的分类器快照它们复用 admission/runtime fixture通过WorkerLifecycle的组合逻辑产生更复杂的结果。例如everyone-left-after-participants的步骤序列是launch → admitted → capture_started → overlapping-speakers两人在线→ nobody-joined全员离开最终判定everyone_left且不可重试。5.1 生命周期中的空场宽限期WorkerLifecycle定义了两个与空会议室相关的默认宽限期lifecycle.rsDEFAULT_NOBODY_JOINED_GRACE 10 * 6010 分钟入会后一直没有人加入 →no_one_joined可重试DEFAULT_EVERYONE_LEFT_GRACE 2 * 602 分钟曾有过其他参与者、随后全部离开 →everyone_left不可重试。WorkerLifecycle内部用saw_other_participants与empty_since跟踪是否见过其他人与空场起始时间从而区分no_one_joined从未有人来与everyone_left有人来过又走光两种语义完全不同的结局。5.2 供应商无关的终止原因枚举生命周期层把所有可能的结局归一化为统一的TerminalReasonKindcrates/meeting-capture/src/lifecycle.rs它通过#[serde(rename_all snake_case)]序列化为矩阵中列出的字符串是整个 worker 与上层控制面通信的公共语言枚举变体序列化值语义MeetingEndedmeeting_ended会议结束StoppedByRequeststopped_by_request上层主动停止AdmissionDeniedadmission_denied主持人拒绝入会AdmissionTimeoutadmission_timeout等待室超时NoOneJoinedno_one_joined一直无人入会EveryoneLefteveryone_left全员离开RemovedFromMeetingremoved_from_meeting被移出会议RecordingPermissionDeniedrecording_permission_denied录制权限被拒InvalidMeetinginvalid_meeting会议无效AuthenticationFailedauthentication_failed认证失败含验证码未过CapacityExceededcapacity_exceeded容量超限NetworkLostnetwork_lost网络中断ProviderErrorprovider_error提供商错误含错误页WorkerExitedworker_exited工作进程崩溃退出Unknownunknown未知原因每个TerminalReason携带kind、可选message与retryable标志crates/meeting-capture/src/lifecycle.rs。BotState状态机则约束了合法的状态迁移Queued → Launching → WaitingForAdmission/Joined → Capturing → Completed/Failed并强制终态必须携带终止原因、非终态不得携带任何非法迁移都会返回TransitionError。六、测试验证fixture_replay.rs 如何回放矩阵fixture_replay.rs 是矩阵文档的可执行版本包含两个核心测试6.1 回放全部分类器快照replays_every_vexa_classifier_fixture遍历fixtures/vexa-v0.12.18/admission与runtime目录下的全部 JSON先断言数量不少于 12 个保证矩阵 fixture 被完整提交然后对每个快照用elapsed_ms 0先classify一次模拟初始观察再以started elapsed_ms的时间点classify第二次模拟宽限期后的观察将两次结果与expected字段断言admitted→AdmissionOutcome::Admittedwaiting→WaitingForAdmissionconsent→ConsentRequiredrejected→ 检查reason与indicatorruntime 侧则断言active/removed/meeting_ended/network_lost及对应的 indicator 文案。6.2 回放生命周期场景replays_lifecycle_scenarios_to_provider_neutral_terminal_reasons逐个执行scenarios.json中的场景把steps翻译为WorkerLifecycle的方法调用launch→launch_started()admission/runtime→ 加载对应 fixture 并调用observe_admission()/observe_runtime()elapsed_ms 0时先做一次初始观察admission_timeout→admission_timed_out()worker_exited→worker_exited(message)stt_unavailable→stt_unavailable(message)stopped_by_request→stopped_by_request()每一步产生的CaptureEventPayload::Lifecycle(transition)会记录终止原因场景结束时断言lifecycle.state()为failed/completed/canceled中的期望值且最后一条reason.kind与retryable与场景声明完全一致。scenarios.json中每个场景都定义了expected_state、expected_terminal与retryable三个断言目标例如{ id: network-lost-after-grace, expected_state: failed, expected_terminal: network_lost, retryable: true, steps: [ { action: launch }, { action: admission, fixture: admission/admitted.json }, { action: capture_started }, { action: runtime, fixture: runtime/network-lost.json } ] }14 个场景覆盖了 happy pathhost-ended-meeting→meeting_ended/completed、各类失败host-denied-before-join→admission_denied/failed、可重试故障worker-crash-after-join→worker_exited/retryable、stt-outage→provider_error/retryable以及主动停止stopped-by-request→stopped_by_request/completed等边界情况。七、如何扩展矩阵与复现验证如果你需要新增一个 Google Meet 行为场景可以遵循仓库内既有的三步流程采集快照在 admission_probe.js、runtime_probe.js被ADMISSION_PROBE_EXPRESSION/RUNTIME_PROBE_EXPRESSION编译期内嵌的基础上通过 CDP 页面求值得到归一化snapshot登记矩阵在fixtures/vexa-v0.12.18/admission或runtime下新增 JSON含id/kind/elapsed_ms/snapshot/expected需要多步组合时在scenarios.json增加场景条目跑测试验证执行cargo test测试入口为 fixture_replay.rs回放测试会自动拾取新 fixture 并断言分类结果完整的在线验证路径可参考 live_google_meet.rs 与 reliability_gate.rs。整体而言这份行为矩阵的设计精髓在于把外部第三方Vexa的复杂页面行为转化为不依赖其内部实现的归一化快照 确定性分类器 状态机场景回放让 Anarlog 的 Google Meet Worker 在离线、可复现、可审计的前提下稳定地把页面上发生了什么翻译成上层控制面能够理解的、供应商无关的终止原因与重试策略。【免费下载链接】anarlogOpen source Granola AI Alternative项目地址: https://gitcode.com/GitHub_Trending/hy/anarlog创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Anarlog 的 Vexa v0.12.18 Google Meet 行为矩阵：准入/运行时分类器与生命周期终止原因全解
Anarlog 的 Vexa v0.12.18 Google Meet 行为矩阵准入/运行时分类器与生命周期终止原因全解【免费下载链接】anarlogOpen source Granola AI Alternative项目地址: https://gitcode.com/GitHub_Trending/hy/anarlog导读本文以 Anarlog 企业版 Google Meet Workerenterprise/google-meet-worker仓库中固定版本 Vexav0.12.18的行为矩阵behavior matrix文档为核心系统拆解其准入admission与运行时runtime状态分类器、14 个生命周期lifecycle场景及其供应商无关的终止原因terminal reason语义。读完本文你将掌握 Google Meet 会议机器人在加入→被拒→等待→入会→被移除→断网→会议结束等全链路状态下的判定逻辑、宽限期grace参数、可重试语义以及这些行为是如何通过可回放replayable的 JSON 快照进行自动化验证的。一、矩阵文档的定位与设计初衷1.1 Pinned Reference固定版本的行为契约MATRIX.md 开头明确了这份矩阵的基准Pinned reference: Vexav0.12.18, commit1b62993e7e97c6ee04a5dcb116f7749ec74169df.Vexa 是一个开源的会议录制/转录机器人项目Anarlog 在 enterprise Google Meet Worker 中采纳了其准入与运行时分类器的行为并将其以归一化normalized快照的形式固化为可回放的 fixture。关键点在于文档自己强调的These fixtures are replayable snapshots of normalized Anarlog admission/runtime classifiers. They do not require Vexa internals at test time.也就是说测试时完全不依赖 Vexa 的内部实现只需要这些归一化后的快照数据即可驱动 Anarlog 自己的分类器。这种做法把第三方行为沉淀为可复现的测试资产避免测试因上游变化而漂移。从实现上看分类器代码在文件头也明确标注了来源见 admission.rs 与 runtime.rs 首行注释Adapted for Anarlog from Vexa v0.12.18并在 THIRD_PARTY_NOTICES.md 与 VEXA-LICENSE 中保留了完整的第三方版权与许可说明。1.2 fixture 的目录结构fixture 快照被组织在 fixtures/vexa-v0.12.18 下admission/准入阶段的页面状态快照6 个runtime/入会并开始捕获后的页面状态快照10 个scenarios.json跨越多个快照、按时间轴回放的生命周期场景14 个MATRIX.md行为矩阵文档本身。每个快照 JSON 都是一个页面探针probe输出的归一化结果例如 admission/host-denied.json{ id: host-denied, kind: admission, elapsed_ms: 0, snapshot: { waiting_room_visible: true, consent_prompt_visible: false, explicit_denial_indicator: denied your request, ambiguous_error_indicator: null, visible_recaptcha_challenge: false, participant_tile_labels: [], self_name_nodes: 0, visible_admission_controls: 0 }, expected: { outcome: rejected, reason: host_denied, indicator: denied your request } }顶层expected字段声明了该快照应当被分类出的结果测试直接拿它做断言基准。二、行为矩阵总览16 个 fixture 快照2.1 准入阶段admission6 个FixtureVexa 模块Anarlog outcomeTerminal reasonRetryableadmission/host-denied.jsonjoin/src/googlemeet/admission.tsRejected HostDeniedadmission_deniednoadmission/waiting-room.jsonjoin/src/googlemeet/admission.tsWaitingForAdmission——admission/admitted.jsonjoin/src/googlemeet/join.tsAdmitted——admission/captcha-unsolved.jsonjoin/src/googlemeet/admission.tsRejected CaptchaUnsolvedauthentication_failednoadmission/error-page.jsonjoin/src/googlemeet/admission.tsRejected ErrorPageprovider_errornoadmission/consent.jsonjoin/src/googlemeet/admission.tsConsentRequired——准入阶段覆盖了三种终态拒绝HostDenied / CaptchaUnsolved / ErrorPage与三种非终态等待WaitingForAdmission / Admitted / ConsentRequired。其中终态拒绝分别映射为admission_denied、authentication_failed、provider_error且全部不可重试——它们代表 Google 侧的确定性拒绝重试没有意义。2.2 运行时阶段runtime10 个FixtureVexa 模块Anarlog outcomeTerminal reasonRetryableruntime/removed.jsonjoin/src/googlemeet/removal.tsRemovedremoved_from_meetingnoruntime/meeting-ended.jsonjoin/src/googlemeet/removal.tsMeetingEndedmeeting_endednoruntime/network-lost.jsonjoin/src/googlemeet/removal.tsNetworkLost after gracenetwork_lostyesruntime/active.jsongmeet-capture/src/gmeet-capture.tsActive——runtime/silence.jsongmeet-capture/src/pcm-capture.tsActive (no tiles besides bot)no_one_joinedafter graceyesruntime/nobody-joined.jsongmeet-capture/src/pcm-capture.tsActive until empty-room graceno_one_joinedyesruntime/overlapping-speakers.jsongmeet-capture/src/gmeet-speakers.tsActive with two named tiles——runtime/speaker-renamed.jsongmeet-capture/src/gmeet-speakers.tsActive with renamed tile——runtime/unresolved-speaker.jsongmeet-capture/src/gmeet-speakers.tsActive with chrome chrome-ui tile——runtime/long-duration.jsongmeet-capture/src/gmeet-capture.tsActive after two hours——注意runtime/silence.json的含义机器人已入会有 self tile但没有任何其他参会者画面此时短时仍判Active只有当空场宽限期empty-room grace耗尽后才转换为no_one_joined且可重试——网络瞬断或无人入会属于环境问题重新调度会话是合理的。三、准入分类器AdmissionClassifier源码级解析行为矩阵中的 6 个 admission fixture 正是 admission.rs 中AdmissionClassifier::classify的输入输出契约。3.1 快照结构AdmissionSnapshotAdmissionSnapshotadmission.rs包含 8 个字段全部来自浏览器页面探针字段类型含义waiting_room_visiblebool等待室waiting room是否可见consent_prompt_visiblebool同意/授权弹窗是否可见explicit_denial_indicatorOptionString明确的拒绝文案如 denied your requestambiguous_error_indicatorOptionString模糊错误文案如 Try againvisible_recaptcha_challengebool是否出现 reCAPTCHA 人机验证participant_tile_labelsVecString参与者画面上的名字标签列表self_name_nodesusize页面上自身名字节点数量visible_admission_controlsusize可见的准入控制组件数量其中real_participant_tiles()会过滤掉 Google Meet 的 visual_effects / Backgrounds and effects 这类装饰性标签避免把特效预览误判为真实参会者——这一点有专门单测effects_preview_is_not_a_real_participant验证admission.rs 测试模块。3.2 分类决策顺序classifyadmission.rs按确定性优先级依次判定一旦命中即返回显式拒绝 一切只要explicit_denial_indicator存在直接Rejected(HostDenied)。即使同时出现 reCAPTCHA 与等待室副本也照样以拒绝为准单测explicit_host_denial_wins_over_captcha_and_stale_waiting_copy覆盖。模糊错误 reCAPTCHA进入验证码宽限期DEFAULT_CAPTCHA_GRACE 120s。宽限期内返回CaptchaChallenge { remaining }持续等待超过 120 秒仍未解决则Rejected(CaptchaUnsolved)。单测captcha_suppression_expires_instead_of_polling_forever验证了宽限到期前 1 秒仍在等待、到期即拒绝的边界。模糊错误无验证码Rejected(ErrorPage)对应页面渲染出错。等待室可见WaitingForAdmission机器人滞留等待室。同意弹窗可见ConsentRequired需要用户/管理员授权。存在准入信号真实参与者画面、自身名字节点、准入控件任一非零Admitted。以上皆非Unknown等待下一次探针。单测waiting_and_consent_guards_suppress_lobby_false_positives还保证了即使等待室/同意弹窗场景下出现了准入控件或参与者标签也不会被误判为Admitted。3.3 fixture 与宽限期的对应admission/captcha-unsolved.json的elapsed_ms为120000即 120 秒正好等于DEFAULT_CAPTCHA_GRACE——fixture 通过elapsed_ms字段模拟验证码已超时从而让测试在不真实等待 2 分钟的情况下验证 CaptchaUnsolved 的终态。四、运行时分类器RuntimeClassifier源码级解析运行时阶段的 10 个 fixture 对应 runtime.rs 中的RuntimeClassifier::classifyruntime.rs。4.1 快照结构与判定优先级RuntimeSnapshot结构更简单removal_indicator、meeting_ended_indicator、connection_problem_indicator三个 Option 文案 participant_tile_labels/self_name_nodes/visible_meeting_controls三个活跃信号。判定顺序为被移除 会议结束 断网removal_indicator如 you were removed优先于meeting_ended_indicatormeeting ended再优先于connection_problem_indicatorreconnecting。单测explicit_removal_wins_over_ended_and_connection_copy验证了这一优先级。断网宽限期DEFAULT_CONNECTION_GRACE 30s。出现connection_problem_indicator后 30 秒内返回ConnectionInterrupted { remaining }网络恢复则回到 Active超过 30 秒才升级为NetworkLost。单测transient_reconnection_has_a_bounded_grace_period精确验证了30 秒整时切换为 NetworkLost。活跃信号判定与准入类似self_name_nodes/visible_meeting_controls/ 非装饰性参与者标签任一存在即Active。未知状态不能无限轮询DEFAULT_RUNTIME_UNKNOWN_GRACE 30s连续 30 秒没有任何信号则进入StateLost单测unknown_runtime_state_cannot_poll_forever覆盖。4.2 两个关键 fixture 的对照runtime/network-lost.jsonelapsed_ms 3000030 秒connection_problem_indicator reconnecting正好越过连接宽限期得出NetworkLost。这与DEFAULT_CONNECTION_GRACE一一对应。runtime/silence.jsonelapsed_ms 0只有自身 tileself_name_nodes: 1没有其他人——立即判Active空场宽限期在生命周期层处理见下一节。五、生命周期场景scenarios.json 与 14 个终止原因scenarios.json 把上述快照按时间轴串成多步场景通过 lifecycle.rs 的WorkerLifecycle状态机回放最终断言供应商无关的终止原因。矩阵文档给出的额外场景表ScenarioTerminal reasonRetryableeveryone-left-after-participantseveryone_leftnosilence-then-nobody-joinedno_one_joinedyeshost-ended-after-long-capturemeeting_endednocaptcha-unsolvedauthentication_failednoerror-page-before-joinprovider_errornostopped-by-requeststopped_by_requestno这 6 个场景是组合行为而非新的分类器快照它们复用 admission/runtime fixture通过WorkerLifecycle的组合逻辑产生更复杂的结果。例如everyone-left-after-participants的步骤序列是launch → admitted → capture_started → overlapping-speakers两人在线→ nobody-joined全员离开最终判定everyone_left且不可重试。5.1 生命周期中的空场宽限期WorkerLifecycle定义了两个与空会议室相关的默认宽限期lifecycle.rsDEFAULT_NOBODY_JOINED_GRACE 10 * 6010 分钟入会后一直没有人加入 →no_one_joined可重试DEFAULT_EVERYONE_LEFT_GRACE 2 * 602 分钟曾有过其他参与者、随后全部离开 →everyone_left不可重试。WorkerLifecycle内部用saw_other_participants与empty_since跟踪是否见过其他人与空场起始时间从而区分no_one_joined从未有人来与everyone_left有人来过又走光两种语义完全不同的结局。5.2 供应商无关的终止原因枚举生命周期层把所有可能的结局归一化为统一的TerminalReasonKindcrates/meeting-capture/src/lifecycle.rs它通过#[serde(rename_all snake_case)]序列化为矩阵中列出的字符串是整个 worker 与上层控制面通信的公共语言枚举变体序列化值语义MeetingEndedmeeting_ended会议结束StoppedByRequeststopped_by_request上层主动停止AdmissionDeniedadmission_denied主持人拒绝入会AdmissionTimeoutadmission_timeout等待室超时NoOneJoinedno_one_joined一直无人入会EveryoneLefteveryone_left全员离开RemovedFromMeetingremoved_from_meeting被移出会议RecordingPermissionDeniedrecording_permission_denied录制权限被拒InvalidMeetinginvalid_meeting会议无效AuthenticationFailedauthentication_failed认证失败含验证码未过CapacityExceededcapacity_exceeded容量超限NetworkLostnetwork_lost网络中断ProviderErrorprovider_error提供商错误含错误页WorkerExitedworker_exited工作进程崩溃退出Unknownunknown未知原因每个TerminalReason携带kind、可选message与retryable标志crates/meeting-capture/src/lifecycle.rs。BotState状态机则约束了合法的状态迁移Queued → Launching → WaitingForAdmission/Joined → Capturing → Completed/Failed并强制终态必须携带终止原因、非终态不得携带任何非法迁移都会返回TransitionError。六、测试验证fixture_replay.rs 如何回放矩阵fixture_replay.rs 是矩阵文档的可执行版本包含两个核心测试6.1 回放全部分类器快照replays_every_vexa_classifier_fixture遍历fixtures/vexa-v0.12.18/admission与runtime目录下的全部 JSON先断言数量不少于 12 个保证矩阵 fixture 被完整提交然后对每个快照用elapsed_ms 0先classify一次模拟初始观察再以started elapsed_ms的时间点classify第二次模拟宽限期后的观察将两次结果与expected字段断言admitted→AdmissionOutcome::Admittedwaiting→WaitingForAdmissionconsent→ConsentRequiredrejected→ 检查reason与indicatorruntime 侧则断言active/removed/meeting_ended/network_lost及对应的 indicator 文案。6.2 回放生命周期场景replays_lifecycle_scenarios_to_provider_neutral_terminal_reasons逐个执行scenarios.json中的场景把steps翻译为WorkerLifecycle的方法调用launch→launch_started()admission/runtime→ 加载对应 fixture 并调用observe_admission()/observe_runtime()elapsed_ms 0时先做一次初始观察admission_timeout→admission_timed_out()worker_exited→worker_exited(message)stt_unavailable→stt_unavailable(message)stopped_by_request→stopped_by_request()每一步产生的CaptureEventPayload::Lifecycle(transition)会记录终止原因场景结束时断言lifecycle.state()为failed/completed/canceled中的期望值且最后一条reason.kind与retryable与场景声明完全一致。scenarios.json中每个场景都定义了expected_state、expected_terminal与retryable三个断言目标例如{ id: network-lost-after-grace, expected_state: failed, expected_terminal: network_lost, retryable: true, steps: [ { action: launch }, { action: admission, fixture: admission/admitted.json }, { action: capture_started }, { action: runtime, fixture: runtime/network-lost.json } ] }14 个场景覆盖了 happy pathhost-ended-meeting→meeting_ended/completed、各类失败host-denied-before-join→admission_denied/failed、可重试故障worker-crash-after-join→worker_exited/retryable、stt-outage→provider_error/retryable以及主动停止stopped-by-request→stopped_by_request/completed等边界情况。七、如何扩展矩阵与复现验证如果你需要新增一个 Google Meet 行为场景可以遵循仓库内既有的三步流程采集快照在 admission_probe.js、runtime_probe.js被ADMISSION_PROBE_EXPRESSION/RUNTIME_PROBE_EXPRESSION编译期内嵌的基础上通过 CDP 页面求值得到归一化snapshot登记矩阵在fixtures/vexa-v0.12.18/admission或runtime下新增 JSON含id/kind/elapsed_ms/snapshot/expected需要多步组合时在scenarios.json增加场景条目跑测试验证执行cargo test测试入口为 fixture_replay.rs回放测试会自动拾取新 fixture 并断言分类结果完整的在线验证路径可参考 live_google_meet.rs 与 reliability_gate.rs。整体而言这份行为矩阵的设计精髓在于把外部第三方Vexa的复杂页面行为转化为不依赖其内部实现的归一化快照 确定性分类器 状态机场景回放让 Anarlog 的 Google Meet Worker 在离线、可复现、可审计的前提下稳定地把页面上发生了什么翻译成上层控制面能够理解的、供应商无关的终止原因与重试策略。【免费下载链接】anarlogOpen source Granola AI Alternative项目地址: https://gitcode.com/GitHub_Trending/hy/anarlog创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考