DanielLeens commented on PR #10808:
URL: https://github.com/apache/seatunnel/pull/10808#issuecomment-5852831301
@SEZ9 — fair ask, here are the exact hunks from the current head
(`0d4d8624c`), not just a description.
**F5** — `docs/en/engines/zeta/rest-api-v1.md`, lines 581-587 (fetched the
file directly at this SHA, not a diff, since these lines are unchanged from
earlier rounds):
```
- `nodeRole`: statically configured node capability. Valid values are
`MASTER`, `WORKER`, and
`MASTER_AND_WORKER`.
- `coordinator`: whether this node is configured with coordinator capability.
- `worker`: whether this node is configured with worker capability.
`nodeRole`, `coordinator`, and `worker` disclose the cluster topology. The
REST API V1 has no
authentication, so restrict network access to it when this information is
sensitive.
```
That's the full paragraph, unbroken — the truncation you saw earlier was a
GitHub comment-rendering artifact on my side's quoting, not a gap in the file
itself.
**F8** —
`seatunnel-core/seatunnel-starter/src/test/java/org/apache/seatunnel/core/starter/seatunnel/command/ServerExecuteCommandTest.java`
at `0d4d8624c`:
- Line 37: `import java.util.Collections;`
- Line 114:
`command.getActiveMasterAddress(Collections.singletonList(coordinatorMember),
null);`
- Line 177: `Collections.singletonList(coordinatorMaster),
coordinatorMaster);`
A full-file grep for `java\.util\.Collections` against this exact file
returns only the import line — no inline FQN reference remains anywhere else in
the file.
For F1-F4, F6, F7, here's the direct evidence per item, all verified against
`0d4d8624c`:
- **F1/F2** (CLI re-derives the active coordinator client-side instead of
asking the server for its resolved view): `ServerExecuteCommand.java`, method
`describeActiveMasterResolution(Member masterMember, Address
activeMasterAddress)` (Javadoc + body around lines 196-223). It does **not**
switch the CLI to a server-side source of truth — it labels the existing
client-side inference as best effort: returns `"Active master: UNKNOWN..."`
when nothing resolves, or `"Active master: %s (best effort)..."` when Hazelcast
mastership sits on a lite member. `showClusterMembers()` calls it (line 157)
and prints the result under the member table. That matches the lower-effort
alternative you offered in an earlier comment ("or make the fallback clearly
best-effort in the output"), not a switch to a server-side lookup — flagging
that distinction explicitly so you can judge for yourself whether it fully
satisfies your original ask or only the alternative you were willing to accept.
- **F3/F7** (incompatible-changes.md missing the failover-window /
CLI-semantics note): `docs/en/introduction/concepts/incompatible-changes.md`,
lines 328-329. Line 328 documents the new `ACTIVE MASTER` CLI semantics (a
worker-only Hazelcast master now shows as `WORKER`, plus the
best-effort/UNKNOWN wording tied to F1/F2/F6). Line 329 documents the failover
window itself: "While a coordinator is being elected or while no
coordinator-capable member is visible, no node reports `isMaster=true`... Alert
rules must tolerate this short window instead of treating it as a lost cluster."
- **F4** (telemetry.md missing the timeout value/configurability):
`docs/en/engines/zeta/telemetry.md`, lines 196-197: "SeaTunnel attempts a final
best-effort `ReportMetricsOperation` flush with a bounded timeout of 1 second.
This value is fixed and not configurable."
- **F6** (unknown-coordinator state shows every non-lite member as plain
`MASTER`): same `describeActiveMasterResolution` as F1/F2 above. `getRole()`
itself (defined right after, starting at line 225) is unchanged and still
prints a plain per-row `MASTER`/`WORKER` label — the ambiguity is resolved by
the new note line `describeActiveMasterResolution` prints underneath the table,
not by changing the row label itself. Worth you independently judging whether
closing it via an added note (rather than changing the row-rendering contract)
actually satisfies your original ask.
On `mergeStateStatus`/`Build`: no disagreement, nothing has changed since
either of our last notes — still `DIRTY`/`FAILURE` on this exact head, still
blocking regardless of how the doc/CLI items above land.
--
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]
