I was curious and dug into the Go client code. You linked to the definition of KV – the easiest way to create one is with NewKV [1], which internally creates a RetryKV [2] wrapper around the Client you give it.
RetryKV implements the KV methods by delegating to the underlying client. But before it delegates an immutable request (e.g., range), it sets the request retry policy to repeatable [3].
Retries are implemented with a gRPC interceptor, which checks the retry policy when deciding whether a request should be retried [4].
The Jepsen writeup says a client can retry a request when “the client can prove the first request could never execute, or that the request is idempotent”. In my (cold) read of the code, the Go client stays within those bounds.
For non-idempotent requests, the Go client only retries when it knows the request was never sent in the first place [5]. For idempotent requests, any response with gRPC status unavailable will be retried [6].
Unlike jetcd, the Go client’s retry behavior is safe.
The linked issue was reported on an Android player app; the underlying yt-dlp issue seems to be https://github.com/yt-dlp/yt-dlp/issues/10397 (intermittent HTTP 403 Forbidden responses from YouTube when downloading videos).
If you want to precisely capture when a field must be present (or will always be set on the server), the field_behavior annotation captures more of the nuance than proto2's required fields: https://github.com/googleapis/googleapis/blob/master/google/...
You could (e.g.) annotate all key fields as IDENTIFIERs. Client code can assume those will always be set in server responses, but are optional when making an RPC request to create that resource.
(This may just work in theory, though – I’m not sure which code generators have good support for field_behavior.)
Location: San Francisco Bay Area (Oakland)
Remote: yes
Willing to relocate: no
Technologies: Rust, Go, TypeScript, Kubernetes, AWS, Terraform, GraphQL
Résumé/CV: https://lyra.engineer/resume.pdf
Github: https://github.com/silverlyra
Email: lyra+hn [at] omg.lol
I'm an experienced infrastructure and full-stack engineer. Over my time working at Medium, I led the redevelopment of its production environment, migrating the whole site and all services onto Kubernetes, and facilitating safe continuous deployment for all engineering teams.
I can serve as a tech lead of a team or a project, working across a company to get things done, and also as a staff+-level IC in smaller companies or greenfield projects.
It’s much more isolation than C threads – the entry point for a thread is a whole module (not a function), and threads must use message passing to communicate. They can share memory, but only via [Shared]ArrayBuffer objects. They're in the same OS process, but each have their own global process object.
But I think it'd meet your need for an in-process isolated execution environment, which you can terminate from the main thread after a timeout.
If you use SharedArrayBuffers in worker threads, use Atomics.wait to block, and then terminate the worker which would've called Atomics.notify – yes, if no timeout is used on the notify.
But I don't know of any other way this would happen.
V8 isolate termination is more akin to throwing an uncatchable exception, versus killing a thread abruptly. When you ask v8 to terminate an isolate, it does take some time for it to terminate depending on what code is running.
> Hertz could have become the EV rental company if they turned every rental office they have in the US to a fast charging center
They did build out fast charging – but at some locations, the local electric utility couldn't support it:
> While the company had installed its own charging network as part of the electrification push that started in 2021, some older airports, such as New Jersey’s Newark, don’t get enough power from the electricity grid or lack the infrastructure to support the number of so-called Superchargers that Hertz needed to get EVs back on the road in a half-hour or less. Once a Tesla was returned to those locations, Hertz employees often had to drive them for miles to find a Supercharger[…]
The image of Hertz staff driving around Jersey, searching for an open supercharger any time a Tesla needed a fast turnaround … tragicomedy.
I would think that only a gradual pilot rollout of Tesla rentals could have saved this from getting out of hand. Instead they ordered 100,000 full-price Teslas, and congratulated themselves on getting a lock on a market … a market which proved to be much smaller and more expensive to serve than they'd imagined.
Location: San Francisco Bay Area (Oakland)
Remote: yes
Willing to relocate: no
Technologies: Rust, Go, TypeScript, Kubernetes, AWS, Terraform, GraphQL
Résumé/CV: https://lyra.engineer/resume.pdf
Github: https://github.com/silverlyra
Email: lyra+hn [at] omg.lol
I'm an experienced infrastructure and full-stack engineer. Over my time working at Medium, I led the redevelopment of its production environment, migrating the whole site and all services onto Kubernetes, and facilitating safe continuous deployment for all engineering teams.
I can serve as a tech lead of a team or a project, working across a company to get things done, and also as a staff+-level IC in smaller companies or greenfield projects.
Looks like it does – you can add a rule to set the enabled option to false for all devDependencies. It’s the third example in the docs for the enabled option:
RetryKV implements the KV methods by delegating to the underlying client. But before it delegates an immutable request (e.g., range), it sets the request retry policy to repeatable [3].
Retries are implemented with a gRPC interceptor, which checks the retry policy when deciding whether a request should be retried [4].
The Jepsen writeup says a client can retry a request when “the client can prove the first request could never execute, or that the request is idempotent”. In my (cold) read of the code, the Go client stays within those bounds.
For non-idempotent requests, the Go client only retries when it knows the request was never sent in the first place [5]. For idempotent requests, any response with gRPC status unavailable will be retried [6].
Unlike jetcd, the Go client’s retry behavior is safe.
[1] https://github.com/etcd-io/etcd/blob/main/client/v3/kv.go#L9... [2] https://github.com/etcd-io/etcd/blob/main/client/v3/retry.go... [3] https://github.com/etcd-io/etcd/blob/main/client/v3/retry_in... [4] https://github.com/etcd-io/etcd/blob/main/client/v3/retry_in... [5] https://github.com/etcd-io/etcd/blob/main/client/v3/retry.go... [6] https://github.com/etcd-io/etcd/blob/main/client/v3/retry.go...