Hacktoberfest 2026:維護者為十月標記出來的 issue,仍然開放、適合新手。 瀏覽 Hacktoberfest issue

Complexity of async rust

未關閉
#188 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

評估

難度
5/5
預估耗時
一週以上
新手友好度
30/100
Issue 類型
重構
描述清晰度
需要釐清
活躍度
活躍
技術堆疊
python, rust
領域
backend

研究方向

The issue names OpsQueue and the async transaction function but no file or test. Start by tracing that function and related async call sites, then evaluate whether the async usage can be simplified or replaced. Done requires an agreed scope and measurable simplification, which the issue does not yet define.

由索引模型根據 Issue 內容生成。

描述

discussion

The complexity of OpsQueue in terms of the work being done is not particularly high, OpsQueue does not have many database tables, it performs some queries on these tables and provides a HTTP API and Rust/Python FFI layers.

However the complexity of some of the code that implements this work is quite high, the issue being that this raises the barrier to new contributors and increases time needed to implement new features or maintain existing ones. For example when reading the following code a new (or existing) contributor may begin to scratch their head 😃

    async fn transaction<O, E, F>(&mut self, f: F) -> Result<O, E>
    where
        for<'t> F: FnOnce(Conn<Self::Writable, Tx<'t, '_>>) -> BoxFuture<'t, Result<O, E>>
            + Send
            + Sync
            + 't,
        O: Send,
        E: From<sqlx::Error> + Send,

The purpose of this issue is as a place to discuss whether it would be possible to simplify/replace any aspects of the code in relation to the async usage.

主要語言
Rust
星號
96
分支
2
PR 合併指標
30 天內沒有已合併 PR

環境準備

我們還沒有檢查這個專案的環境設定檔。先看它的 README,通用步驟見我們的新手貢獻指南。

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

channable/opsqueue 的其他 Issue

查看 channable/opsqueue 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。