Hand a device-scored sequence back to the API model when the device stops scoring
维护者通常 6 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 42/100
调研方向
Read #723 and inspect the sequence scoring worker, the sequences model, and its migrations; the payload does not name file paths or tests. Compare the proposed frame-count fallback with the engine signal alternative, including how each distinguishes an unsupported device model from a failed model. Done means sequences resume API scoring after device scores stop and avoid applying WINDOW_EXHAUSTED from the old device score.
由索引模型根据 Issue 内容生成。
描述
Follow-up of #723. Since that PR a frame without a device score keeps the sequence's last device verdict: the API never falls back to its own model once a sequence received a device score, and the stored score only ever rises.
Edge case. If the device stops sending scores for good in the middle of a sequence (pyro-engine fails open until the end of the event, pyronear/pyro-engine#415) while the stored max is below the threshold, frames keep arriving but nothing judges them anymore: no API scoring, no fail-open, no WINDOW_EXHAUSTED. A real fire on that sequence would never alert. Much less likely than the old single-blip reset, which is why #723 accepted it.
Proposal (fe51).
- store when the device last sent a score, e.g. a
device_scored_atcolumn onsequences(migration); - in the worker, after N frames without a device score (e.g.
MIN_FRAMES), take the API path on the lastMAX_FRAMESframes; - in that case skip the
WINDOW_EXHAUSTEDrule based on the old device score.
Failing open there is acceptable because it only happens after N missed frames, not after one.
Alternative to weigh. The engine knows when it fails open. It could say so explicitly (an empty temporal_model_scores=[], or a dedicated flag) instead of sending nothing, and the API would hand the sequence back to its own model on that signal without counting frames and without a new column. Needs the engine to distinguish "no model on this device" from "model down since frame N".
- 主要语言
- Python
- 星标
- 30
- 派生
- 15
- 平均合并
- 7 天 16 小时
- 30 天内合并 PR
- 16
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
pyronear/pyro-api 的其他 Issue
-
Tests in test_risk_filter.py fail when CI runs shortly after midnight UTC可能已有人在做 @Majyles 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 85/100
维护者通常 6 天内回复
-
难度 4/5 3-5 天 新手友好度 48/100
维护者通常 6 天内回复
-
难度 4/5 3-5 天 新手友好度 45/100
维护者通常 6 天内回复
-
Share an alert with a temporary public link可能已有人在做 @Acruve15 于 8 天前认领。 未关闭type: feat
难度 5/5 一周以上 新手友好度 45/100
维护者通常 6 天内回复
-
type: feat
难度 5/5 一周以上 新手友好度 35/100
维护者通常 6 天内回复
查看 pyronear/pyro-api 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 78/100
huggingface/accelerate#4511 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 84/100
pylint-dev/pylint#11791 ·
维护者通常 1 天内回复
-
Rasterio granule reads never retry, so one 503 (Service Unavailable) fails the whole request可能已有人在做 @chuckwondo 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 75/100
developmentseed/titiler-cmr#305 ·
维护者通常 1 天内回复
-
community enhancement
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复