DanielLeens commented on PR #10808:
URL: https://github.com/apache/seatunnel/pull/10808#issuecomment-5812725696
Thanks for the patience, @SEZ9 - here are the exact diff hunks against
`0d4d8624c` for every remaining item, re-verified just now with `git diff`
against the `dev` merge-base rather than going by description:
**F1/F2 (fallback vs. server-confirmed election):**
- `ServerExecuteCommand.java:182-194` — `getActiveMasterAddress()`, new
method. Returns `null` immediately at `183-184` when `masterMember == null` (no
fallback fires unless Hazelcast has already confirmed a master); the "first
non-lite member" fallback only runs in the `189-193` stream when the confirmed
master is a lite member.
- `ServerExecuteCommand.java:196-223` — `describeActiveMasterResolution()`,
new method. The Javadoc (`199-203`) documents the "best effort... can lag
behind the cluster during failover" rationale, and that exact wording is also
emitted to the operator at `217-219`.
- Tests: `ServerExecuteCommandTest.java:104-117`
(`testUnknownMasterDoesNotSelectFallbackCoordinator`, asserts `null` when
master is unknown) and `:138-160` (`testInferredCoordinatorIsMarkedBestEffort`,
asserts the inferred address + "best effort" wording).
**F6 (unresolved coordinator):**
- `ServerExecuteCommand.java:210-223` — `describeActiveMasterResolution()`;
the `UNKNOWN` branch is `211-213`.
- `ServerExecuteCommand.java:225-235` — `getRole()`; the guard at line `230`
(`masterAddress != null && ...`) is what keeps rows as plain `MASTER` instead
of `ACTIVE MASTER` when nothing was resolved.
- Test: `ServerExecuteCommandTest.java:123-132`
(`testUnknownCoordinatorIsReportedExplicitly`).
**F3/F7 (incompatible-changes entry):**
- `docs/en/introduction/concepts/incompatible-changes.md:322-330` — new `###
Engine Behavior Changes` entry. The `CLI member list` bullet is line `328`, the
`Failover window` bullet is line `329`. Line `328` already contains the
failover-lag caveat in user-facing docs ("the client membership view can lag
behind the cluster"), not only in the Javadoc.
- Mirrored in `docs/zh/introduction/concepts/incompatible-changes.md`, same
entry starting at line `286`.
**F4 (bounded timeout value/configurability):**
- `docs/en/engines/zeta/telemetry.md:52` — `cluster_info{master=...}` now
documented as the active-coordinator address.
- `docs/en/engines/zeta/telemetry.md:196-198` — states "a bounded timeout of
1 second. This value is fixed and not configurable."
**F5 (REST API v1 authentication note):**
- `docs/en/engines/zeta/rest-api-v1.md:525-527` — example response gains
`nodeRole`/`coordinator`/`worker`.
- `docs/en/engines/zeta/rest-api-v1.md:581-587` — field descriptions, ending
with "The REST API V1 has no authentication, so restrict network access to it
when this information is sensitive."
**F8 (Collections import):**
- `ServerExecuteCommandTest.java:37` — `import java.util.Collections;`,
added as a top-of-file import. Used at lines `39` and `102` as
`Collections.singletonList(...)`; no inline FQN remains anywhere in the diff.
All eight items check out against the actual `0d4d8624c` diff, so from my
side F1-F8 are all resolved now.
Live status is unchanged from my last check: `mergeStateStatus` is still
`DIRTY` / `mergeable` is still `CONFLICTING`, and `Build` on `0d4d8624c` is
still `FAILURE`. Once @davidzollo syncs with the latest `dev` and resolves the
conflict, and we get a green run on the synced head, this should be ready to
merge from a source standpoint.
--
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]
