Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#252 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
72/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
python, solidity
Área
blockchain, cli

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Python
Estrellas
4
Forks
7
Merge medio
3 d 58 min
PR fusionados (30 d)
39

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de InfiniteZeroFoundation/DevNet

Todos los issues de InfiniteZeroFoundation/DevNet

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.