numinnex opened a new pull request, #4024:
URL: https://github.com/apache/iggy/pull/4024
A client that commits a metadata write and then re-homes its session onto a
backup can be served the pre-write state. auth.rs already documents the gap:
the session epoch is the register's commit op, and on a backup that forwarded
the proposal the local applied commit still lags it. A backup applies committed
ops only as its commit walk advances, and nothing tied a read to the op the
client's own write committed.
Metadata reads now gate on the connection's committed watermark. One
applied-frontier counter per process advances after every metadata apply and is
shared with every shard, which for the first time gives a shard without
consensus the applied position it had no way to observe. The watermark comes
from the commit field replies already carry, seeded at bind from the session
epoch. The fast path is a single atomic load with no awaits, so the
shared-nothing read path is unchanged; a lagging node parks briefly, then fails
the read retryable rather than answering stale.
Over HTTP this closes the forwarded-register case, where a healthy backup
forwards the register so the bound epoch can exceed the local frontier. It does
not close the case where forwarding is active: the follower relays the write,
its handler never runs, so the node that later serves the read holds no session
and no watermark. Closing that needs the serving primary's commit op to travel
back to the reading node, for instance a response header beside the view the
forward middleware already relays. That is additive but touches every
control-plane write response, so it is left out here and documented at the gate.
The BDD delete-then-get steps now assert "not the stream we deleted" instead
of "nothing at this id". The server hands a deleted stream's numeric id
straight to the next create, so once scenarios share a server the old assertion
cannot hold, and removing the polling loop without this would have left the
spec flaky for an unrelated reason.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
