Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Fermée
  • Quelque chose ne va pas ?
#252 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
72/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
python, solidity
Domaine
blockchain, cli

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Python
Étoiles
4
Forks
7
Merge moyen
3 j 4 h
PR mergées (30 j)
34

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de InfiniteZeroFoundation/DevNet

Toutes les issues de InfiniteZeroFoundation/DevNet

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.