[NODE] `ethtx` task with `from` (field) address always fails with "cannot convert int64"

[beamuu]

Description

I've been running into an issue and would love some help figuring out what's going wrong.

When I specify a literal Ethereum address in the from field of an ethtx pipeline task, the job consistently fails with:

from: AddressSliceParam: cannot convert int64: bad input for task

After digging into the codebase, it looks like the pipeline parameter resolver is silently parsing the address as the JSON number 0 (since all 0x... addresses start with 0, which is a valid standalone JSON token), converting it to int64(0) via ReinterpretJSONNumbers, and then failing when trying to use that int64 as an AddressSliceParam.

I've confirmed this on the latest v2.39.0 — so it doesn't appear to have been addressed yet.

Could you please let me know if the job spec syntax I'm using is correct? Specifically, is specifying a literal address in the from field of an ethtx task a supported usage, or is there a different syntax I should be using instead? I'd really appreciate any guidance!

Basic Information

The behaviour I traced is in the from parameter resolution chain in core/services/pipeline/task.eth_tx.go:103:

From(VarExpr(t.From, vars), JSONWithVarExprs(t.From, vars, false), NonemptyString(t.From), nil)

ResolveParam tries each getter in order and uses the first one that succeeds:

1. VarExpr — correctly skipped (not a $(...) expression)
2. JSONWithVarExprs — incorrectly succeeds: json.Decoder (streaming) reads 0 from 0x<address> as a complete JSON number, leaves the rest of the string unread, then ReinterpretJSONNumbers converts json.Number("0") → int64(0)
3. NonemptyString — never reached

AddressSliceParam.UnmarshalPipelineParam(int64(0)) then hits the default case in task_params.go and returns the error above.

Relevant error log:

2026-03-30T08:32:00.067Z [DEBUG] Completed pipeline run with fatal errors
  pipeline/runner.go:526
  executionID=040df27f-8f83-40e8-bd26-5a1f2d399241
  fatal=true
  run.Errors=["perform(ethtx); from: AddressSliceParam: cannot convert int64: bad input for task"]
  run.FatalErrors=["from: AddressSliceParam: cannot convert int64: bad input for task"]
  run.State=errored
  version=2.39.0@cc3290b

Job spec (observation source excerpt):

perform [type="ethtx"
         from="0x<address>"
         to="0x<contract>"
         data="$(encode_tx)"
         evmChainID="<chain-id>"]

• Chainlink Version: 2.39.0@cc3290b
• Docker Image: smartcontract/chainlink:2.39.0

Steps to Reproduce

1. Run the node using the official Docker image smartcontract/chainlink:2.39.0.
2. Create a cron-based Chainlink job with an ethtx task that uses a literal Ethereum address in the from field (e.g. from="0x<your-address>").
3. Trigger the job.
4. Observe the pipeline run fails with from: AddressSliceParam: cannot convert int64: bad input for task.

Note: this appears to affect all 0x-prefixed Ethereum addresses since they all begin with 0, which happens to be a complete valid JSON number when parsed by Go's streaming json.Decoder.

Root Cause

JSONWithVarExprs in the from resolution chain uses json.Decoder (not json.Unmarshal). The streaming decoder reads exactly one JSON token — 0 — from the input 0x<address> and returns successfully without consuming the rest. After ReinterpretJSONNumbers, this becomes int64(0), which AddressSliceParam cannot handle.

Additional Information

The same JSONWithVarExprs-before-NonemptyString ordering exists for other fields in the same stderrors.Join block (txMeta, transmitChecker). Those fields may be less susceptible since their values don't typically start with a bare JSON number, but the from field is uniquely affected because all Ethereum addresses begin with 0x.

Thanks again for your time — happy to provide any additional information that might help!