kragniz / kragniz/python-etcd3

Let `python-etcd3` renew auth token when expired between calling `Lock.acquire` and `Lock.release`

Open
#2,301 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
450
Forks
194
PR merge metrics
No merged PRs in 30d

Description

How do I let `python-etcd3` renew my auth token when it has expired between calling `Lock.acquire` and `Lock.release`?

Context:

When calling `Lock.release` more than _5 minutes_ after calling `Lock.acquire`, the call fails as the auth token has expired:

```
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
status = StatusCode.UNAUTHENTICATED
details = "etcdserver: invalid auth token"
debug_error_string = "UNKNOWN:Error received from peer ipv6:%5B2a0c:eb00:0:f7:ede:aae:eee:eee%5D:2379 {grpc_message:"etcdserver: invalid auth token", grpc_status:16, created_time:"2023-10-06T14:36:22.040952303+02:00"}"
>
```

This is expected, because etcd's simple token expires after the aforementioned 5 minutes.

FWIW:

* From etcd 3.5, the simple token expiration period can be configured with `--auth-token-ttl`. However:
* - I am on etcd 3.4. And cannot upgrade, as 3.5 is not available in the Debian repositories.
* - Increasing the auth token TTL to be higher than the highest possible lock TTL is not sustainable.
* - As a workaround, I could use JWT and set `–auth-token jwt,ttl=...'`. But https://github.com/kragniz/python-etcd3/issues/779 being the very only mention of JWT for this client implies that it is not supported.
* I have not found a definitive answer on how this client renews the auth token. Not in the documentation nor in the code.
* I also tried re-creating the `Lock` object to call `release()` on, rather than re-using the `Lock` object that I called `acquire()` on (and setting `uuid` to the previous object's, as `Lock.release` requires it to match), but that causes the same error.
* Periodically causing `Lock.refresh` does not refresh the auth token.

Contributor guide

Open the contributing guide

Research direction

The issue names Lock.acquire, Lock.release, and Lock.refresh but no source files or tests. Start by tracing those methods and the client's authentication handling to determine how tokens are obtained and used; done should include reliable token renewal across a long-lived lock and a regression test for release after expiry.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
authentication, backend, distributed-systems
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.