palantir / conjure-rust-runtime Goto Github PK

If you need to make an endpoint that isn't definable in Conjure, you currently have to hand-write all of the metadata, parameter conversion, etc. We should add a macro like Dialogue's annotation processors that would allow you to annotate a set of method definitions and have the inner logic automatically created.

It's probably safest to stick with 0.2 for the next release with the internal restructuring to minimize churn related risk, but then move to 1.0 once things look good.

While Hyper supports HTTP/2 trailers, we don't currently expose that for either request or responses in conjure-rust-runtime. We should do so, probably in a similar way as in palantir/witchcraft-rust-server#35.

FLUP to #56

Implement live-reloading.

Not sure what's going on there since it does report a nonzero server time and the results look right otherwise.

Dialogue listens to a special response header which will reconfigure the client's node selection algorithm.

We currently create a new client each time in ClientFactory, but we should behave like Dialogue and cache them internally to allow for more pooled connection reuse.

We should match Dialogue here.

ClientFactory's client and blocking_client methods currently return the raw Client type. It would be convenient if it could automatically wrap that in arbitrary implementations of the conjure_http::client::Service and conjure_http::client::AsyncService traits. We can probably do this backwards compatibly if we implement Service for Client.

https://github.com/palantir/conjure-rust-runtime/blob/develop/conjure-runtime/src/service/retry.rs#L241-L242

We join on the response headers future and the request body write futures currently. This means that a request flow that's designed to be full-duplex won't work properly. This is probably a really obscure case but we should do better. We may need to e.g. spawn the request body write off onto a new task if request headers come in before the body write completes.

Dialogue's support is in a relatively stable place now.

palantir/dialogue#2165 is one of the big PRs but there are additional changes.

https://github.com/palantir/conjure-rust-runtime/pull/55/files#diff-14aebee6d7a2b67eba22e3e749bb5db2c17eb372df02ffe36741c59ca18505c8R76

To make the implementation more simple, the balanced node selector currently only filters out nodes with high scores once when first building its future, and then selects only on the non-filtered nodes from there. This makes the selector slightly less responsive to score changes while a request is processing which is in theory bad. It's not clear how much this actually matters though.

Fixing it would probably involve wrapping the node score in an async semaphore, and having the future have state for each node that's always waiting for the score to change, and then also waiting on the limiter for nodes that score sufficiently well.

Idempotency is by default derived from the HTTP method. This can be overridden, but only at the client level. We should enable per-request configuration by e.g. looking for a idempotency value in the request extensions.

Right now the client is hard-coded to work with a Hyper client as its low-level HTTP service, but we should allow that to be customized in at least the low-level interfaces to support e.g. a libcurl-based backend or mocked backend for simulations.

These are currently fallible builder APIs, but we should make them staged instead for better compile-time safety.

We currently treat 3xx responses as errors, but we should be handling them properly as redirects. 308 redirects are handled specially in conjure-java-runtime as they're part of the standard Conjure QoS setup, so we'd want to preserve that behavior here most likely.

Our request processing logic is currently open-coded, and a bit complex. We should follow Dialogue's example and switch to composing small transforms. Since Rust has a more robust async implementation than Java it should be significantly less complex than Dialogue's, particularly in the queuing layer.

Rather than the Channel/LimitedChannel concept Dialogue uses, we can probably use tower_service::Service, which Hyper already uses internally.

This will probably require us to drop tower::Service in favor of a Service-like trait that uses &self. This should better match with how we actually use the trait anyway, where we don't do anything interesting with the mutability but still have to pay the cost of it currently.

We currently convert non-2xx status codes into conjure_error::Errors at the very lowest level of our service layers. However, this means we have to in particular take a stack trace very time we see a 429 or 503, and from some profiling of #56 it turns out that a full 35% of the execution time of the simulation set is spent taking those stack traces!

We should instead have the retry layer look at the status codes directly and convert to errors above that point. This probably doesn't matter a ton for "real" workloads where there's actually a network involved but it should still help a bit.

Configuring a client with a single URI with a scheme starting with mesh- should disable client-side QoS and retries.

palantir/dialogue#1048

Dependabot can't resolve your Rust dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

error: failed to parse manifest at `/home/dependabot/dependabot-updater/dependabot_tmp_dir/conjure-verification-api/Cargo.toml`

Caused by:
  package `conjure-verification-api v0.1.0 (/home/dependabot/dependabot-updater/dependabot_tmp_dir/conjure-verification-api)` specifies that it links to `conjure-verification` but does not have a custom build script

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

In particular, Dialogue's client.request metric is significantly more heavily tagged than ours.

When using the deterministic builder option in simulations, we end up creating clients with identical initial states. For the pin until error node selector in particular this isn't great since it means that every client picks the same initial node! We could replace the boolean with a seed instead and have the simulation harness rotate seeds between clients to avoid this.