Chainlink外部适配器提取数组元素及jsonparse索引错误解决咨询

问题根因 #

你遇到的$(decode_cbor.position) is not a valid array index报错，核心原因是消费者合约中通过request.add("position", "1")传递的参数是字符串类型，而jsonparse任务的数组下标要求为整数类型，字符串值无法被识别为合法索引。

你的配置思路本身是可行的，只需要补充类型转换步骤即可正常运行。

修复方案（无需修改外部适配器） #

在任务pipeline中新增类型转换步骤，把字符串格式的position转为整数：

1. 在decode_cbor任务后新增cast_pos类型转换任务：

cast_pos     [type=cast to="uint256" data="$(decode_cbor.position)"]

2. 修改parse任务的path参数，引用转换后的整数值：

parse        [type=jsonparse path="data,MRData,RaceTable,Races,0,Results,$(cast_pos),number" data="$(fetch)"]

3. 调整任务执行流，加入新增的转换步骤：

decode_log -> decode_cbor -> cast_pos -> fetch -> parse -> encode_data -> encode_tx -> submit_tx

更优实现方案（推荐） #

如果可以接受调整逻辑，更建议把position参数传递给外部适配器处理，避免节点侧的路径拼接和类型转换风险：

1. 按照上面的步骤完成position参数的类型转换
2. 修改fetch任务的requestData，把硬编码的position: "0"替换为用户传递的参数：

fetch        [type=bridge name="raceresults" requestData="{\\\"id\\\":$(jobSpec.externalJobID),\\\"data\\\":{\\\"position\\\":$(cast_pos)}}"]

3. 调整外部适配器逻辑，收到position参数后直接返回对应位置的赛车手编号即可，此时parse任务可以简化为：

parse        [type=jsonparse path="data,number" data="$(fetch)"]

这种方案逻辑更清晰，后续如果要调整返回字段也不需要修改节点侧的长路径配置，维护成本更低。

是否需要修改外部适配器？ #

• 如果选择第一种修复方案，完全不需要修改外部适配器逻辑，仅调整节点任务配置即可
• 如果选择第二种更优方案，需要少量修改外部适配器的参数接收和返回逻辑

内容的提问来源于stack exchange，提问作者Daniel