diegomrsantos commented on code in PR #4092:
URL: https://github.com/apache/iggy/pull/4092#discussion_r3983437781
##########
core/server/src/http/handlers.rs:
##########
@@ -1405,17 +1427,18 @@ pub(in crate::http) async fn send_messages(
.map_err(PartitionWriteError::Rejected)?;
match query.ack {
ProduceAck::Replicated => {
+ let policy = topic_durability(&state, &stream_id, &topic_id);
let (reply, header) = SendWrapper::new(partition_write_replicated(
&state,
&identity.session,
Operation::SendMessages,
&body,
))
.await?;
- let durability = [(
- DURABILITY_HEADER,
- HeaderValue::from_static(DURABILITY_REPLICATED_MEMORY),
- )];
+ let policy = policy.map_or(iggy_common::Durability::Replicated,
|policy| {
+ policy.confirmed_policy(&state)
Review Comment:
**[P2] Bind the durability header to the topic actually dispatched**
I found a separate case from the [earlier policy
discussion](https://github.com/apache/iggy/pull/4092#discussion_r3983323849),
still present at `4a38798a5`. Neither topic's durability changes.
Reproduction sequence, with a caller authorized for both topics:
1. Topic A is named `orders` with `durability=persisted`; topic B is named
`fast` with `durability=replicated`.
2. An awaited produce to `orders` captures A's policy here, then waits
behind another write on
[`session.data_gate`](https://github.com/apache/iggy/blob/4a38798a506c9231afdfc83a34ebed394d41dac2/core/server/src/http/submit.rs#L386).
3. While it waits, rename A to `archived` and B to `orders`. Metadata writes
use a separate gate.
4. Dispatch later [resolves the original
name](https://github.com/apache/iggy/blob/4a38798a506c9231afdfc83a34ebed394d41dac2/core/server/src/dispatch/partition.rs#L451)
to B. After B commits,
[`confirmed_policy_in`](https://github.com/apache/iggy/blob/4a38798a506c9231afdfc83a34ebed394d41dac2/core/server/src/http/reads.rs#L429)
validates A's saved numeric identity and creation revision. A still exists, so
the response advertises `Iggy-Durability: persisted` for B's replicated write.
The revision check establishes that A survived; it does not establish that A
received this operation. The header should attest only the guarantee
established by the dispatched operation.
I reran a deterministic unit reproducer on Linux at this head: both real
`UpdateTopicRequest` renames succeed, the resolver selects B, and policy
confirmation returns `Persisted` where the regression expects `Replicated`. The
existing incarnation test passes. This exercises the metadata and policy
helpers; the HTTP waiting sequence above is established by code inspection, not
a full HTTP test.
Could we derive the response policy from the same resolved topic and
incarnation used for dispatch, and retain that association through completion?
--
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]
