You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@paimon.apache.org by "sundapeng (via GitHub)" <gi...@apache.org> on 2026/08/09 00:28:52 UTC

[PR] [rest] Do not replay a POST the server cannot absorb twice [paimon]

sundapeng opened a new pull request, #9122:
URL: https://github.com/apache/paimon/pull/9122

   > **Stacked on #9120 and the S1 PR** — their commits show up here too until they merge. Review only
   > `[rest] Do not replay a POST the server cannot absorb twice`.
   
   ### Purpose
   
   The REST client retries a 429 or a 503 on any request, POST included. That is right for nearly
   everything it sends: registering a partition, creating a database, committing a snapshot the server
   already holds all land on the same state the second time, and the retry is the only defence against a
   rate limiter or a restarting node.
   
   It is wrong for a request that reports an increment. A 429 or a 503 can reach the client **from an
   intermediary after the server already applied the request**, so replaying it applies it again — and an
   increment applied twice is a wrong number that no caller can see. Nothing in the response
   distinguishes the two cases, which is why this has to be decided by the request rather than by the
   status.
   
   `RESTRequest` gains `isRetrySafe()`, defaulting to `true` so **every existing request keeps the retry
   it has today**. A request answering `false` is sent exactly once and the failure reaches the caller,
   which knows whether re-sending is safe.
   
   ### Two details a reviewer will ask about
   
   - The mark travels in the `HttpClientContext` rather than in the request, so it never reaches the wire
     and survives whatever the exec chain does to the request object.
   - `isRetrySafe()` is a getter on a serialized type, so it is `@JsonIgnore`; a test pins that it stays
     out of the body.
   
   ### Compatibility
   
   This PR adds **no** request that answers `false`. The first one arrives with the partition-statistics
   work for catalog-managed format tables, and the ordering matters: with that in and this out, an
   automatic retry double-counts an increment and the server cannot tell a redelivery from a second
   genuine increment.
   
   ### API and Format
   
   `RESTRequest.isRetrySafe()` is a new `default` method returning `true`; existing implementations need
   no change. No format change.
   
   ### Documentation
   
   The contract is in the method javadoc.


-- 
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: issues-unsubscribe@paimon.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] [rest] Do not replay a POST the server cannot absorb twice [paimon]

Posted by "JingsongLi (via GitHub)" <gi...@apache.org>.
JingsongLi commented on PR #9122:
URL: https://github.com/apache/paimon/pull/9122#issuecomment-5236400277

   +1


-- 
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: issues-unsubscribe@paimon.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] [rest] Do not replay a POST the server cannot absorb twice [paimon]

Posted by "JingsongLi (via GitHub)" <gi...@apache.org>.
JingsongLi merged PR #9122:
URL: https://github.com/apache/paimon/pull/9122


-- 
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: issues-unsubscribe@paimon.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org