Add a way to run callbacks after a transaction commits
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
研究方向
Start with opsqueue/src/db/mod.rs, where Connection::transaction() is defined, and read the linked discussion in issues #182 and #193 for context. The issue proposes storing callbacks on transactions, running them after a successful outermost commit, and propagating them from nested transactions. Done means callbacks run only after commit and nested transactions pass them upward; the issue leaves key design details open.
由索引模型根據 Issue 內容生成。
描述
Related: https://github.com/channable/opsqueue/issues/182#issuecomment-5698854050, https://github.com/channable/opsqueue/issues/193
We currently have three things that need to happen after a transaction commits:
- Prometheus metrics accounting.
- Notifying via
notify_on_insert. - Notifying via
submission_status_changed(when https://github.com/channable/opsqueue/pull/187 lands).
Ideally we would like to define these actions close to where they most sense on a semantic level (e.g. within insert_submission). However, once transactions come into play this becomes problematic, because these side-effects should only be executed if and when the transaction commits. Since the callee doesn't control, nor has insight in, if and when that commit would happen we have no choice but to defer that execution to the caller. We currently either ignore the problem (for Prometheus metrics), or handle the defer manually (e.g. by returning a bool, and making the caller check that after commit). Both are not ideal.
To remedy this I propose we offer users of opsqueue::db::Connection::transaction() something like the following API:
conn.transaction(move |mut tx| { async move {
...
// Register a callback to run on commit.
tx.on_commit(|| notify_on_insert.notify());
...
} .boxed()}).await?;
To implement that we would have to:
- Store a list of
on_commitcallbacks somewhere on the transaction (TBD where exactly). - Within
opsqueue::db::Connection::transaction()we check if the transaction committed. If so, and we are not in a nested transaction we execute all the callbacks. If we are in a nested transaction we propagate the callbacks upwards.
- 主要語言
- Rust
- 星號
- 97
- 分支
- 2
- 平均合併
- 1 天 18 小時
- 30 天內合併 PR
- 4
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 有 Pull Request 範本
- 沒有貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
channable/opsqueue 的其他 Issue
-
Reserver does not need to be generic可能已有人在做 @jerbaroo 於 14 天前認領。 未關閉
難度 2/5 1-3 小時 新手友好度 72/100
channable/opsqueue#195 · 已指派 1 人 ·
維護者通常 1 天內回覆
-
Make `submissions_canceled` and `add_chunks_done_to_submissions_failed` migrations bidirectional未關閉
難度 2/5 1-3 小時 新手友好度 74/100
維護者通常 1 天內回覆
-
難度 3/5 1-2 天 新手友好度 68/100
維護者通常 1 天內回覆
-
難度 4/5 3-5 天 新手友好度 45/100
維護者通常 1 天內回覆
-
難度 4/5 3-5 天 新手友好度 35/100
channable/opsqueue#193 · 2 則留言 ·
維護者通常 1 天內回覆
查看 channable/opsqueue 的全部 Issue
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 85/100
penso/herdr-gpui#934 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 76/100
Y-ASLant/ElegantClipboard#178 ·
-
難度 2/5 1-3 小時 新手友好度 82/100
linxiv-dev/linXiv#384 · 1 則留言 ·
維護者通常 1 天內回覆
-
priority middle
難度 2/5 1-3 小時 新手友好度 70/100
KATO-Hiro/AtCoderClans#12945 ·
維護者通常 1 天內回覆
-
bug drawings ui
難度 2/5 1-3 小時 新手友好度 82/100
userFRM/egui-charts#1595 ·
維護者通常 1 天內回覆