related to: #7274 and #7275
Still somewhat uncertain on two things that I'd appreciate more feedback on:
1. The optional temporary local overrides. Perhaps this is superfluous and we can simply make the transition without the override?
2. If this set of parameters seems to be large enough to allow application developers to create the chains they want but not so large as to be needlessly complex.
The parameters for RPC GET requests are parsed from query arguments in the
request URL. Rework this code to remove the need for tmjson. The structure of a
call still requires reflection, and still works the same way as before, but the
code structure has been simplified and cleaned up a bit.
Points of note:
- Consolidate handling of pointer types, so we only need to dereference once.
- Reduce the number of allocations of reflective types.
- Report errors for unsupported types rather than returning untyped nil.
Update the tests as well. There was one test case that checked for an error on
a behaviour the OpenAPI docs explicitly demonstrates as supported, so I fixed
that test case, and also added some new ones for cases that weren't checked.
Related:
* Update e2e base Go image to 1.17 (to match config).
Require that RPC functions take a context as their first argument, and return
an error as either their only result, or the second of two results.
This does not change how functions are dispatched, but will make it a little
easier to make more invasive changes in the near future.
Instead of taking a comma-separated string of parameter names, take each
parameter name as a separate argument. Now that we no longer have an extra flag
for caching, this fits nicely into a variadic trailer.
* Update all usage of NewRPCFunc and NewWSRPCFunc.
Define interfaces for the various methods a service may implement. This is
basically just the set of things on Environment that are exported as RPCs, but
these are also implemented by the light proxy.
* internal/rpc: use NewRoutesMap to construct routes on service start
* light/proxy: use NewRoutesMap to construct RPC routes
Rather than installing two separate panic handlers, defer the bookkeeping
separately from recovery, and lift the delegated handler call out to the top
level of the wrapper.
Also: Regularize the server middleware wrappers.
Add writeRPCResponse and writeHTTPResponse helpers, that handle the way RPC
responses are written to HTTP replies. These replace the exported helpers.
Visible effects:
- JSON results are now marshaled without indentation.
- HTTP status codes are now normalized.
- Cache control headers are no longer set.
Details:
- When writing a response to a URL (GET) request, do not marshal the whole
JSON-RPC object into the body, only encode the result or the error object.
This is a user-visible change.
- Do not change the HTTP status code for RPC errors. The RPC error already
reports what went wrong, the HTTP status should only report problems with the
HTTP transaction itself. This is a user-visible change.
- Encode JSON without indentation in POST response bodies. This is mainly cosmetic
but saves quite a bit of response data. Indent is still applied to GET responses to make
life easier for code examples.
- Remove an obsolete TODO about reporting an HTTP error on websocket upgrade.
Nothing needed to change; the upgrader already reports an error.
- Report an HTTP error when starting the server loop fails.
- Improve logging for encoding errors.
- Log less aggressively.
In two cases, we check for the content of an error right after asserting that
no error occurs. Fix the sense of those checks.
In one case, we check that there is no error with the diagnostic "expected
error". It's not clear whether this means "an error was expected" (which is
what I believe) or "we got the expected error". However, given the way the mock
plumbing is set up, the first interpretation seems right.
We should not set cache-control headers on RPC responses. HTTP caching
interacts poorly with resources that are expected to change frequently, or
whose rate of change is unpredictable.
More subtly, all calls to the POST endpoint use the same URL, which means a
cacheable response from one call may actually "hide" an uncacheable response
from a subsequent one. This is less of a problem for the GET endpoints, but
that means the behaviour of RPCs varies depending on which HTTP method your
client happens to use. Websocket requests were already marked statically
uncacheable, adding yet a third combination.
To address this:
- Stop setting cache-control headers.
- Update the tests that were checking for those headers.
- Remove the flags to request cache-control.
Apart from affecting the HTTP response headers, this change does not modify the
behaviour of any of the RPC methods.
Bumps [github.com/BurntSushi/toml](https://github.com/BurntSushi/toml) from 0.4.1 to 1.0.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/BurntSushi/toml/releases">github.com/BurntSushi/toml's releases</a>.</em></p>
<blockquote>
<h2>v1.0.0</h2>
<p>This release adds much more detailed errors, support for the <code>toml.Marshaler</code> interface, and several fixes.</p>
<p>There is no special meaning in the jump to v1.0; the 0.x releases were always treated as if they're 1.x with regards to compatibility; the versioning scheme for this library predates the release of modules.</p>
<h2>New features</h2>
<ul>
<li>
<p>Error reporting is much improved; the reported position of errors should now always be correct and the library can print more detailed errors (<a href="https://github-redirect.dependabot.com/BurntSushi/toml/issues/299">#299</a>, <a href="https://github-redirect.dependabot.com/BurntSushi/toml/issues/332">#332</a>)</p>
<p>Decode always return a <code>toml.ParseError</code>, which has three methods:</p>
<ul>
<li>
<p><code>Error()</code> behaves as before and shows a single concise line with the error.</p>
</li>
<li>
<p><code>ErrorWithLocation()</code> shows the same error, but also shows the line the error occurred at, similar to e.g. clang or the Rust compiler.</p>
</li>
<li>
<p><code>ErrorWithUsage()</code> is the same as <code>ErrorWithPosition()</code>, but may also show a longer usage guidance message. This isn't always present (in which case it behaves identical to <code>ErrorWithPosition()</code>), but it should be present for most common mistakes and sources of confusion.</p>
</li>
</ul>
<p>Which error the correct one to use is depends on your application and preferences; in general I would recommend using at least <code>ErrorWithPosition()</code> for user-facing errors, as it's much more helpful for users of any skill level. If your users are likely to be non-technical then <code>ErrorWithUsage()</code> is probably a good idea; I did my best to avoid technical jargon such as "newline" and phrase things in a way that's understandable by most people not intimately familiar with these sort of things.</p>
<p>Additionally, the TOML key that fialed should now always be reported in all errors.</p>
</li>
<li>
<p>Add <code>toml.Marshaler</code> interface. This can be used if you want full control over how something is marshalled as TOML, similar to <code>json.Marshaler</code> etc. This takes precedence over <code>encoding.TextMarshaler</code>. (<a href="https://github-redirect.dependabot.com/BurntSushi/toml/issues/327">#327</a>)</p>
</li>
<li>
<p>Allow TOML integers to be decoded to a Go float (<a href="https://github-redirect.dependabot.com/BurntSushi/toml/issues/325">#325</a>)</p>
<p>Previously <code>int = 42</code> could only be decoded to an <code>int*</code> type; now this can also be decoded in a <code>float</code> type as long as it can be represented without loss of data.</p>
</li>
</ul>
<h2>Fixes</h2>
<ul>
<li>
<p>Key.String() is now quoted when needed (<a href="https://github-redirect.dependabot.com/BurntSushi/toml/issues/333">#333</a>)</p>
</li>
<li>
<p>Fix decoding of nested structs on 32bit platforms (<a href="https://github-redirect.dependabot.com/BurntSushi/toml/issues/314">#314</a>)</p>
</li>
<li>
<p>Empty slices are now always <code>[]T{}</code> rather than nil, which was the behaviour in v0.3.1 and before. While they are identical for most purposes, encoding/json encodes them different (<code>[]</code> vs. <code>null</code>), making it an (accidentally) incompatible change (<a href="https://github-redirect.dependabot.com/BurntSushi/toml/issues/339">#339</a>)</p>
</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="4272474656"><code>4272474</code></a> Reject control characters everywhere</li>
<li><a href="9bbaaec997"><code>9bbaaec</code></a> Update toml-test</li>
<li><a href="8a54f3e8df"><code>8a54f3e</code></a> Merge TestDecodeInterfaceSlice in TestDecodeSlices</li>
<li><a href="9515b92979"><code>9515b92</code></a> Decode S=[] into a non-nil []interface{}. (<a href="https://github-redirect.dependabot.com/BurntSushi/toml/issues/339">#339</a>)</li>
<li><a href="7d0236fe74"><code>7d0236f</code></a> Make sure quoted keys with dots work well (<a href="https://github-redirect.dependabot.com/BurntSushi/toml/issues/333">#333</a>)</li>
<li><a href="ff0a3f89c2"><code>ff0a3f8</code></a> Add back build tags for toml-test files</li>
<li><a href="7356d5f888"><code>7356d5f</code></a> Few staticcheck fixes</li>
<li><a href="b1471ff6cf"><code>b1471ff</code></a> Don't allow "0_0"</li>
<li><a href="847ee8a07a"><code>847ee8a</code></a> Update toml-test</li>
<li><a href="461925704e"><code>4619257</code></a> Clearer errors when decoding to invalid types (<a href="https://github-redirect.dependabot.com/BurntSushi/toml/issues/332">#332</a>)</li>
<li>Additional commits viewable in <a href="https://github.com/BurntSushi/toml/compare/v0.4.1...v1.0.0">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
</details>
* Rename rpctypes.Context to CallInfo.
Add methods to attach and recover this value from a context.Context.
* Rework RPC method handlers to accept "real" contexts.
- Replace *rpctypes.Context arguments with context.Context.
- Update usage of RPC context fields to use CallInfo.
No functional changes.
- Pull out a some helper code to simplify the control flow within the body of
the HTTP request handler.
- Front-load the URL path check so it does not get repeated for each request.
Instead of using anonymous maps, define tagged struct types for JSON argument
encoding. This allows us to have the encoding rules we want without tmjson.
This commit handles the "easy" cases. BroadcastEvidence is omitted here,
because it depends on the interface encoding rules from tmjson. I will address
that in a forthcoming change.
Defines a different concrete type that satisfies the service interface for a seed node.
update the seed node unit test to assert the new type.
Fixes#6775
* Update Caller interface and its documentation.
* Rework MapToRequest as ParamsToRequest.
The old interface returned the result as well as populating it. Nothing was
using this, so drop the duplicated value from the return signature. Clarify the
documentation on the Caller type.
Rework the MapToRequest helper to take an arbitrary value instead of only a
map. This is groundwork for getting rid of the custom marshaling code. For now,
however, the implementation preserves the existing behaviour for the map, until
we can replace those.
These two interfaces are identical, and besides HTTPClient being confusingly
named, all but one location uses Caller. Update that one location, and drop the
redundant interface.
Apart from the tests for the websocket client, positional parameters are not
used by RPC clients. The server supports both arrays and objects, but the
client only needs to provide one or the other.
Where possible, replace uses of the custom JSON library with the standard
library. The custom library treats interface and unnamed lteral types
differently, so this change avoids those even where it would probably be safe
to switch them.
Sam Kleinman
William Banfield
M. J. Fromberger
dependabot[bot]
Kene