Question about the post-auth raft roundtrip in JWT Authenticate

[DCjanus]

While reading the JWT auth path, I ran into one part I may be misunderstanding.

Relevant code

• EtcdServer.Authenticate does:
  • linearizableReadNotify
  • local CheckPassword
  • raftRequestOnce
• on apply, applierV3backend.Authenticate calls AuthStore.Authenticate(...)
• for JWT, tokenJWT.assign appears to sign locally from (username, revision, exp)

Question

For JWT specifically, is the post-auth raft proposal required for semantics, or is it mainly a consequence of the shared auth path?

From the current implementation, my reading is that the extra raft roundtrip may not be needed for token generation itself, so I wanted to understand what guarantee it is meant to provide.

For example, is it needed for:

1. ordering / linearizability after password verification
2. auth revision consistency
3. audit / apply-path semantics
4. or is it mostly an implementation choice shared with non-JWT token backends?

The reason I am asking is operational. After a network disruption, we had many clients re-authenticate at once, and this path became quite expensive.

I suspect external JWT infrastructure may be the cleaner long-term answer, but for operational reasons we still prefer etcd-native JWT if possible. Before thinking about any optimization here, I wanted to first understand the design intent.

[DCjanus]

For some additional context from our side:

In our internal etcd fork, we temporarily removed both the linearizable read before JWT auth and the raft proposal after auth to understand where the cost was coming from. In our stress tests, that improved authentication throughput by about 10x with 50 concurrent clients, and about 100x with around 5000 concurrent clients.

That said, I understand removing the linearizable read is probably not realistic upstream because of the consistency tradeoff.

So the more specific question for us is whether the post-auth raft proposal is semantically required for JWT, or whether it is mainly a consequence of the current shared implementation path.

I also realize that changing this may not be practical upstream if it requires broader semantic changes. I am mainly trying to understand whether there is some deeper constraint here, beyond code structure, that makes removing the post-auth proposal unsafe or non-viable.