The standard “Hello, World!” of testing a Chainlink Node is to execute the “Get > Uint256” job that’s referenced in the documentation. Its simple, the smart contract sends a request to the oracle contract and it in turn executed the “Get > Uint256” job, fetching a single number from a JSON web api.
Fetching a string-value from that same JSON web api has turned out to me a bit more difficult, limiting and frustrating.
TLDR: the solution can be found here
Get > Bytes32
What an innocuous little title for a job that has caused me so much grief today 😑. Lets just share it in all of its glory:
type = "directrequest"
schemaVersion = 1
name = "Get > Bytes32 v14"
maxTaskDuration = "0s"
contractAddress = "0x17A8182DBF79427801573A3D75d42eB9B1215DEF"
minIncomingConfirmations = 0
observationSource = """
decode_log [type="ethabidecodelog"
abi="OracleRequest(bytes32 indexed specId, address requester, bytes32 requestId, uint256 payment, address callbackAddr, bytes4 callbackFunctionId, uint256 cancelExpiration, uint256 dataVersion, bytes data)"
data="$(jobRun.logData)"
topics="$(jobRun.logTopics)"]
decode_cbor [type="cborparse" data="$(decode_log.data)"]
fetch [type="http" method=GET url="$(decode_cbor.get)"]
parse [type="jsonparse" path="$(decode_cbor.path)" data="$(fetch)"]
encode_data [type="ethabiencode" abi="(bytes8 value)" data="{ \\"value\\": $(parse) }"]
encode_tx [type="ethabiencode"
abi="fulfillOracleRequest(bytes32 requestId, uint256 payment, address callbackAddress, bytes4 callbackFunctionId, uint256 expiration, bytes32 data)"
data="{\\"requestId\\": $(decode_log.requestId), \\"payment\\": $(decode_log.payment), \\"callbackAddress\\": $(decode_log.callbackAddr), \\"callbackFunctionId\\": $(decode_log.callbackFunctionId), \\"expiration\\": $(decode_log.cancelExpiration), \\"data\\": $(encode_data)}"
]
submit_tx [type="ethtx" to="0x17A8182DBF79427801573A3D75d42eB9B1215DEF" data="$(encode_tx)"]
decode_log -> decode_cbor -> fetch -> parse -> encode_data -> encode_tx -> submit_tx
"""
The import individual steps of the job are in the observationSource section. After two steps to decode the incoming request, the node performs a fetch retrieving the URL specified in the job request payload. The request data is returned and pushed through parse which extracts a specific value from the JSON.
The interesting and ultimately disappointing steps happen during encode_data and encode_tx. In the version above the encode_data step attempts to convert the string-value returned from parse as a bytes8 which is great if your string-value fits into that data structure.
"Coinbase" # is returned from parse as bytes8
"ETH" # is returned from parse as bytes3
So when in encode_data you try and pass a bytes3 into a ethabiencode you get an error :
expected 8, got 3: bad input for task: bad input for task
Frustrating that ethabiencode can’t upscale the bytes3 into a bytes8.
My next approach was to see if I could make those string-values convert to dynamic rather than fix-length data structures, so I rewrote encode_data:
# changing the abi to a dynamic bytes array - "(bytes value)"
encode_data [type="ethabiencode" abi="(bytes value)" data="{ \\"value\\": $(parse) }"]
This got me one step further by upscaling any string-value into a bytes96. However this is where encode_tx abruptly grounded to a halt, as the fulfillOracleRequest(....., bytes32 data) method requires the data to be passed back as a bytes32.
In summary
Right now I can’t see anyway around having to specify exact fixed-size datastructures, i.e. bytes3 when parse returns a small string, and the slightly larger bytes8 when it returns a bigger string.
This doesn’t feel like a workable solution. I’ve got a couple of further options to pursue, most notably the concept of larger responses.
Follow Up
I finally managed to fetch a large string using the large responses technique mentioned above. Instructions can be found here.