dongjoon-hyun commented on PR #853: URL: https://github.com/apache/spark-kubernetes-operator/pull/853#issuecomment-5752105604
Thanks for the re-check, and for catching finding 4 — you are right that the description had drifted from what the code actually does, and it is the version that persists in the commit message. Updated. "Why" no longer names a 500 or a network failure as the problem, since neither changed behavior: it now says that "not there" and "could not be read" were the same value, that for the statuses the create loop retries the conflation works out anyway (create succeeds, or hits `AlreadyExists` and the re-read settles it), and that a refusal is the case where it does not — the create has no more standing than the read did, so the write goes out for nothing and the error that surfaces names the create rather than the read that failed first. "What changes" drops "a failure that did not reach a healthy API server" and lists the absent bucket as what it is. One deliberate wording choice there. I wrote "the transient codes `isTransientError` covers" rather than naming network failures, because I am not yet sure that bucket does what its comment says. `isTransientError` treats `0` as the network sentinel, but in kubernetes-client 7.8.0 `OperationSupport.requestException(HttpRequest, Throwable, String)` builds the exception with `iconst_m1`, i.e. code `-1`. If that is the path a connection reset takes, then `case 0` never matches one, and the pre-existing comment at the transient re-read — "GET to avoid duplicate create attempt for timeouts (0)" — would not be doing anything either. I have only confirmed the constant in the bytecode so far, not the end-to-end path, so I did not want to assert the network-failure behavior in a description that becomes the commit message. It is `main` code and predates this PR, so I will chase it separately rather than widen this one; flagging it here in case you have context on when that constructor is used. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
