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 于 13 天前认领。 未关闭
难度 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
-
priority middle
难度 1/5 1 小时以内 新手友好度 62/100
KATO-Hiro/AtCoderClans#12940 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 83/100
维护者通常 1 天内回复
-
o8 next debug build aborts on Glass to Dark appearance switch (nil identifier messaged before check)未关闭bug
难度 2/5 1-3 小时 新手友好度 78/100
hurttlocker/o8#5112 ·
-
难度 2/5 1-3 小时 新手友好度 79/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复