fix: connectedComponents max_iter default evaluated to 31 due to ^ precedence - #902

What changes were proposed in this pull request?

GraphFrame.connectedComponents declared its max_iter default as 2 ^ 31 - 2. In Python ^ is
bitwise XOR and - binds tighter than ^, so the expression is 2 ^ 29, which evaluates to 31
rather than the intended 2 ** 31 - 2 (2147483646):

$ python -c "print(2 ^ 31 - 2)"
31

Three changes, all under python/:

1. The fix — python/graphframes/graphframe.py: max_iter: int = 2 ^ 31 - 2 becomes
   max_iter: int = 2**31 - 2.

2. A docstring entry — connectedComponents had no :param max_iter: line at all. Added three
   lines in the style of its neighbours, noting that it applies only to algorithm="graphx" and
   that the other algorithms ignore it.

3. Two regression tests in python/tests/test_graphframes.py:

   • test_connected_components_graphx_default_max_iter_is_unlimited — behavioural. A 50-vertex
     path graph (diameter 49) run with algorithm="graphx" and no max_iter argument, so the
     default itself is what is under test.
   • test_connected_components_max_iter_default_value — a signature guard that catches a
     ** → ^ regression without starting Spark.

   Both are plain functions on the existing module-scoped spark fixture, with no mode-specific
   branches or skips, so they run unchanged in classic, Connect and thin-client modes.

Red/green. On the unfixed tree the behavioural test fails with exactly the count a 31-superstep
cap predicts:

>       assert result.select("component").distinct().count() == 1
E       AssertionError: assert 19 == 1

Vertices 0–31 collapse onto component 0; vertices 32–49 retain 18 stale labels, giving 19.
result.count() == 50 passes, so all rows are present and only the component assignment is wrong —
the failure mode is silent. With the fix, both tests pass in classic and in Connect mode.

No Scala, build, protobuf or CI files are touched:

$ git diff --stat
 python/graphframes/graphframe.py |  5 ++++-
 python/tests/test_graphframes.py | 23 +++++++++++++++++++++++
 2 files changed, 27 insertions(+), 1 deletion(-)

Why are the changes needed?

The Python default is always forwarded to the JVM (graphframe.py → classic/graphframe.py
java_cc.maxIter(max_iter), and over Spark Connect via ConnectedComponents.max_iter), so the
Scala-side default of Int.MaxValue never applies when calling from Python.

ConnectedComponents.scala:143 passes maxIter only to runGraphX, which hands it straight to
Pregel(...); that loop is while (isActiveMessagesNonEmpty && i < maxIterations) with no
convergence check. The result is that algorithm="graphx" returns silently wrong, split
components for any graph needing more than 31 supersteps — no exception, no warning. For a
long-diameter graph (identity resolution, session/device linkage) that is a correctness incident,
not a performance nuisance.

This is a defect against stated intent rather than a behaviour change:
docs/src/04-user-guide/05-traversals.md:318 already documents the maxIter default as
Integer.MAX_VALUE (unlimited).

Scope is limited to algorithm="graphx" — TwoPhase.scala and RandomizedContraction.scala
contain no references to maxIter and run to convergence regardless.

The existing suite does exercise algorithm="graphx" (PREGEL_ARGUMENTS at
test_graphframes.py:40), but test_connected_components / test_connected_components2 use 1- and
2-vertex graphs, whose diameter is far below 31 — which is why this was never caught.

One question for maintainers: the minimal fix is the corrected literal. An alternative would be
max_iter: int | None = None, forwarding only when set and letting
maxIter.getOrElse(Int.MaxValue) govern. That is arguably cleaner but widens the public signature
and touches both backends, so I have not assumed it here — happy to follow up separately if you
prefer it.

Local verification

Run on Windows 11 / JDK 17.0.20.1 against the workflow definitions.