smartcontractkit / smartcontractkit/chainlink
[DEVEL] Notation for json data parameters in V2 toml jobs
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 8.2k
- Forks
- 2k
- Avg merge
- 1d 23h
- Merged PRs (30d)
- 202
Description
Hey, regarding toml specs:
In vrf-spec.toml and keeper-spec.toml the data parameter for ethabiencode is using the escaped body notation, whereas in direct-request-spec-cbor.toml and multiword-response-spec.toml, the much more readable angled-bracket-curly-bracket notation is used.
Is is correct to assume that the angled bracket notation will be used going forward?
In vrf-spec.toml a txMeta parameter is provided to the ethtx task, but it is also using escaped body notation. Will ethtx.txMeta parameter also use angled bracket notation going forward?
Same questions apply to http.requestData parameter.
Another question not related to json. Re. tasks usd_multiply, eur_multiply and jpy_multiply in multiword-response-spec.toml: is that comma supposed to be there?
Thank you : )
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Compare the parameter notation in vrf-spec.toml, keeper-spec.toml, direct-request-spec-cbor.toml, and multiword-response-spec.toml, focusing on data, txMeta, and http.requestData. Check the usd_multiply, eur_multiply, and jpy_multiply task definitions for the reported comma, then confirm the intended notation and syntax with maintainers; done means the specs and their documented conventions are unambiguous.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100