feat(benchmark): add disable/enable and rename to participant

[RapidPoseidon]

What

Adds three lifecycle methods to BenchmarkParticipant in the Python SDK:

• disable() — disables the participant, excluding it from evaluation and standings (sets status to Disabled).
• enable() — re-enables a previously disabled participant (sets status back to Submitted). Added as the natural inverse so disable() is reversible from the SDK.
• rename(name) — updates the participant's name and reflects it on the local object.

All three wrap existing backend endpoints (participant/{id}/disable, .../enable, .../name) via the generated participant_api, and follow the existing tracing-span pattern used by delete() / get_elo().

Docs

Added "Renaming a Participant" and "Disabling Participants" sections to docs/mri_advanced.md.

Checks

• uv run pyright src/rapidata/rapidata_client → 0 errors
• uv run black src/rapidata/rapidata_client → clean
• uv run --group docs mkdocs build → builds (only pre-existing unrelated warnings)

🔗 Session: ${POSEIDON_SESSION_URL:-$HOSTNAME}

[claude]

Code Review

PR: feat(benchmark): add disable/enable and rename to participant
Files changed: 2 (+62 lines, 0 deletions)

---

Overview

Adds three lifecycle methods — disable(), enable(), rename() — to BenchmarkParticipant, wrapping existing backend endpoints. The pattern is consistent with the existing delete() / get_elo() methods and the documentation additions are clear and appropriately scoped.

---

Issues

Bug — enable() unconditionally sets status to SUBMITTED

def enable(self) -> None:
    ...
    self._status = ParticipantStatus.SUBMITTED  # always SUBMITTED

If a participant is in CREATED state (media uploaded but not yet submitted via run()) and is then disabled, calling enable() will incorrectly advance its local status to SUBMITTED. The server-side state may differ. Either:

• Track the pre-disable status and restore it, or
• Re-fetch the participant status from the backend after enabling, or
• Document clearly that enable() is only valid on a previously-submitted participant (and guard accordingly).

Deferred import in rename() should be at the module level

def rename(self, name: str) -> None:
    from rapidata.api_client.models.update_participant_name_endpoint_input import (
        UpdateParticipantNameEndpointInput,
    )
    ...

The deferred import in _process_single_sample_upload makes sense (hot path, potentially avoids circular imports). Here there is no such reason — UpdateParticipantNameEndpointInput should sit alongside the existing top-level import of ParticipantStatus. As written it also means the import statement executes on every call, though Python caches it after the first hit.

---

Minor Suggestions

No input validation on rename() — an empty string or whitespace-only name will reach the backend without any client-side feedback. A simple guard keeps error messages friendlier:

def rename(self, name: str) -> None:
    if not name or not name.strip():
        raise ValueError("name must be a non-empty string")
    ...

run() is missing a tracer span — the three new methods all follow the with tracer.start_as_current_span(...) pattern, but the pre-existing run() does not. Not introduced by this PR, but worth aligning while the file is open.

---

Positives

• All three methods correctly update local state only after the API call succeeds — good ordering.
• Tracing span names follow the existing "BenchmarkParticipant.<method>" convention exactly.
• Docs additions are concise and show the reversible disable/enable relationship clearly without over-explaining.
• Pyright and Black checks confirmed passing per the PR description.