Guard costs[i] bounds in estimateAndAssignTxCost to fix panic under Go 1.27

[Copilot]

PR #93 bumps the Docker builder from golang:1.26.5-alpine to golang:1.27rc2-alpine, which exposed a latent bug: estimateAndAssignTxCost accesses costs[i] in a logging loop without checking whether sim.Costs() returned a slice of the same length as op.Contents. When those lengths diverge (e.g. a minimal/synthetic simulation receipt), this causes an index-out-of-bounds crash — manifesting as fatal error: stack overflow under Go 1.27rc2.

Changes

• internal/tezos/prepare_transaction.go — add i >= len(costs) guard in the estimateAndAssignTxCost debug logging loop; emit a reduced log line (without simulation cost fields) for any op entry that has no corresponding simulation result:

costs := sim.Costs()
for i, v := range op.Contents {
    // ...
    if i >= len(costs) {
        log.L(ctx).Debugf("OP#%03d: %s fee(%s)=%d ... (no simulation cost data)", ...)
        continue
    }
    log.L(ctx).Debugf("OP#%03d: %s gas_used(sim)=%d ...", ..., costs[i].GasUsed, ...)
}

• internal/tezos/prepare_transaction_test.go — add Test_estimateAndAssignTxCostFewerSimResultsThanOpContents which passes an op with two contents entries against a mock that returns only one simulation result, directly exercising the new bounds check.

[alex-semenyuk]

@copilot

Error: FF23016: Invalid output type: wrong
#17 41.04 Usage:
#17 41.04 tezosconnect version [flags]

[Copilot]

@copilot

Error: FF23016: Invalid output type: wrong
...

That output (Error: FF23016: Invalid output type: wrong) is expected — it comes from TestVersionCmdInvalidType, which tests the error path and passes correctly.

The real CI failure was the docker-build job (using golang:1.27rc2-alpine), where TestTransactionPrepareSuccess crashed with fatal error: stack overflow. The full stack trace reveals the root cause:

(*micheline.Parameters).UnmarshalJSON in tzgo calls json.Unmarshal(data, alias(p)) where type alias *Parameters. In Go ≤1.26 this avoided recursion, but Go 1.27's new encoding/json/v2 backend resolves the method set of the underlying type, so it calls (*Parameters).UnmarshalJSON again — infinite recursion until the stack overflows.

Fixed in commit a2e0008 → bypassed the buggy method with a local unmarshalParameters helper that uses a plain struct alias (no UnmarshalJSON method) to parse the same three JSON formats.

[alex-semenyuk]

@copilot can you push directly to dependabot/docker/docker-0c7ab30260

[Copilot]

@copilot can you push directly to dependabot/docker/docker-0c7ab30260

Unfortunately I can only push to the branch associated with this PR (copilot/dependabotdockerdocker-0c7ab30260) — I don't have direct push access to dependabot/docker/docker-0c7ab30260. You could merge or cherry-pick my changes from this PR into that branch manually.