Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

dincli: create-testdataset --submit sets the one-shot TestDataAssignedFlag even when a batch's assignment tx failed

Đang mở
  • Có gì không ổn?
#252 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
72/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
python, solidity
Lĩnh vực
blockchain, cli

Hướng nghiên cứu

Start in dincli/cli/modelownerd/auditor_batches.py around lines 198-253 and check how build_and_send_tx reports success or failure. Trace the one-shot flag behavior in foundry/src/DINTaskAuditor.sol around lines 1033-1046. Done means failed batch IDs are reported and the flag is set only after every assignment succeeds; run the relevant CLI tests if available.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Approved bug

Summary

model-owner auditor-batches create-testdataset --submit loops over every auditor batch sending assignAuditTestDataset, never checks whether any individual batch's transaction actually succeeded, and then unconditionally sets a one-shot "all test data assigned" flag on-chain regardless. If one batch's assignment silently failed, the contract is left permanently asserting something that isn't true, with no way to go back and fix just that batch.

Where

dincli/cli/modelownerd/auditor_batches.py (~lines 198-253), verified against develop (fetched fresh):

for batch_id in range(audtor_batch_count):
    ...
    build_and_send_tx(
        ctx,
        taskauditor_contract.functions.assignAuditTestDataset(
            curr_GI, batch_id, encrypted_cid, encrypted_keys, commitment
        ),
        f"Assigning test dataset for auditor batch {batch_id}",
        f"Test dataset assigned for auditor batch : {batch_id}",
        f"Failed to assign test dataset for auditor batch : {batch_id}",
        exit_on_failure=False,   # return value discarded, loop continues regardless
    )

time.sleep(5)
build_and_send_tx(
    ctx,
    taskCoordinator_contract.functions.setTestDataAssignedFlag(curr_GI, True),   # unconditional
    "Setting test dataset assigned flag",
    "Test dataset assigned for auditor batches",
    "Failed to set test dataset assigned flag",
    exit_on_failure=False,
)

setTestDataAssignedFlag (foundry/src/DINTaskAuditor.sol:1033-1046) is one-shot — TA_FlagAlreadySet on any second call:

function setTestDataAssignedFlag(uint _GI, bool flag) external onlyTaskCoordinator onlyCurrentGI(_GI) returns (bool) {
    if (dintaskcoordinatorContract.GIstate() != GIstates.AuditorsBatchesCreated)
        revert TA_CannotSetTestDataAssignedFlag();
    if (!flag) revert TA_FlagMustBeTrue();
    if (Is_testdataCIDs_Assigned[_GI]) revert TA_FlagAlreadySet();   // <-- no way back
    Is_testdataCIDs_Assigned[_GI] = flag;
    return true;
}

Failure sequence

  1. Batch 0's assignAuditTestDataset succeeds. Batch 1's fails (RPC hiccup, gas, anything build_and_send_tx catches internally) — it prints a red error line and returns None, but the loop just moves on to batch 2 since the return value is never inspected.
  2. The loop finishes anyway. setTestDataAssignedFlag(curr_GI, True) still runs and succeeds — nothing on-chain or in the CLI ties that flag to whether every batch's assignment actually landed.
  3. Auditors assigned to batch 1 later call encryptedTestDataKey(gi, 1, their_address) during evaluation (dincli/cli/auditor.py:477-479) and get empty bytes back, so Box(...).decrypt(...) throws — caught generically at auditor.py:498-500 as "failed to decrypt test data." The auditor has no way to tell the real cause is an incomplete assignment on the model owner's side, not something wrong on their end.
  4. No recovery path exists. Even after noticing and fixing/retrying batch 1's assignAuditTestDataset (which itself has no on-chain one-shot guard, so it CAN be retried), the CLI only exposes it bundled inside this all-or-nothing loop — no --batch option to retry a single one — and setTestDataAssignedFlag can't be called again to "re-confirm" since it's already True. The on-chain record permanently asserts "test data fully assigned for this GI" when it isn't.

Impact

Any auditor assigned to the batch that silently failed is unable to evaluate for that entire GI, with a misleading error message, and the model owner has no way to detect or fix the gap after the fact — the flag already says everything's fine.

Suggested fix

Collect each batch's build_and_send_tx return value in the loop; only call setTestDataAssignedFlag if every batch succeeded. On partial failure, report exactly which batch IDs failed and exit before setting the flag, so the operator can retry (ideally via a --batch <id> option to resubmit just the failed one(s) without re-running the whole loop) before the one-shot flag gets set.

Ngôn ngữ chính
Python
Star
4
Fork
7
Merge trung bình
3 ngày 58 phút
Pull request đã merge (30 ngày)
39

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của InfiniteZeroFoundation/DevNet

Tất cả issue của InfiniteZeroFoundation/DevNet

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.