Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#252 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
72/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
python, solidity
Ambito
blockchain, cli

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Python
Stelle
4
Fork
7
Merge medio
3g 58m
PR unite (30g)
39

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di InfiniteZeroFoundation/DevNet

Tutte le issue di InfiniteZeroFoundation/DevNet

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.