Fix Test Code Samples: select a non-owner member in fleet-api orgs sample

[btshrewsbury-viam]

Problem

The Test Code Samples job (test-code-snippets.yml) has failed on every run since 2025-11-10 — both the weekly scheduled runs and every dependabot/push run. Because the Python step runs first and exits non-zero, the Go and TypeScript sample steps never run, so this also blocks validation of unrelated dependency bumps.

The single failing file is static/include/examples/fleet-api/fleet-management-api-orgs.py. Today's run: 28/29 Python samples pass; this one fails at the add_role call (line ~197):

grpclib.exceptions.GRPCError: (<Status.INTERNAL: 13>,
  'cannot add authorization: user a46bc9ee-… has inherited location_owner
   permissions on resource pg5q3j3h95 with resource type location')

Root cause

The sample selected member_list[-1] (the last org member) for the add_role → change_role → remove_role lifecycle. Member ordering isn't guaranteed, and the test org's membership has since changed so the last member is now an org owner. Org owners inherit location_owner on every location, so adding a location-level owner role to them is rejected by the backend.

This is an environmental regression, not a code change — the file was unchanged when the job went red on Nov 10 (the next edits to it were Nov 13/27/28, after it was already failing).

Fix

Select a member who holds no existing authorizations (so they can't inherit location_owner) instead of relying on list position:

existing_authorizations = await cloud.list_authorizations(org_id=ORG_ID)
privileged_identity_ids = {a.identity_id for a in existing_authorizations}
user_id = next(
    (m.user_id for m in member_list if m.user_id not in privileged_identity_ids),
    None,
)
assert user_id is not None, "Expected at least one organization member without existing authorizations ..."

add_role then grants a genuinely new authorization regardless of member ordering, and the downstream change_role/remove_role and count assertions hold. If no roleless member exists, the new assert fails with a clear message instead of a cryptic GRPCError.

Verification

• python -m py_compile passes; AST parses.
• ⚠️ Not run against the live Viam API — the test requires VIAM_API_KEY/TEST_ORG_ID/etc., which are GitHub Actions secrets unavailable locally. Please confirm via the Test Code Samples workflow on this branch (or a maintainer re-run) that the org has at least one member without existing authorizations. If the test org happens to contain only owners, the new assert will surface that explicitly and a non-owner member should be added to the org.

🤖 Generated with Claude Code

[netlify]

✅ Deploy Preview for viam-docs ready!

Name	Link
🔨 Latest commit	c797d9c
🔍 Latest deploy log	https://app.netlify.com/projects/viam-docs/deploys/6a3dbb74e4af0d00089ca814
😎 Deploy Preview	https://deploy-preview-5106--viam-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 40 (🟢 up 4 from production) Accessibility: 100 (no change from production) Best Practices: 100 (no change from production) SEO: 92 (no change from production) PWA: 70 (no change from production) View the detailed breakdown and full score reports

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[btshrewsbury-viam]

Verified via workflow_dispatch on this branch (run 28253085953)

The fix behaves exactly as designed and confirms the root cause. The new assert fired:

AssertionError: Expected at least one organization member without existing
authorizations to test add_role/change_role/remove_role.

→ The docs-scheduled-tests test org currently has no member without an existing authorization, so no member can receive a fresh location_owner role without already inheriting it. This is a test-org data problem, not a list-position bug — which is why member_list[-1] happened to fail.

Required to make orgs.py pass (org-admin action, not code)

Invite/add a member to docs-scheduled-tests (TEST_ORG_ID) with no roles. Once such a member exists, the code in this PR selects them deterministically and the full add_role → change_role → remove_role lifecycle is exercised. Keeping the assert (rather than a silent skip) is intentional so the org-membership requirement stays visible.

Out of scope for this PR (separate issues found in the same run)

• data-pipelines/pipeline-create.py and pipeline-list.py fail on teardown delete_data_pipeline() with GRPCError(INTERNAL, "an internal error occurred"). These passed in the prior run, so they look like transient backend errors; re-running to confirm.
• The Login to Jira / Create Jira ticket steps also fail, so failure notifications for this long-broken job may not have been firing.

[btshrewsbury-viam]

Confirmation re-run (28253912502): data-pipelines flakiness verified

Second workflow_dispatch run with no code change: 28/29 passed. data-pipelines/pipeline-create.py and pipeline-list.py passed this time, confirming their delete_data_pipeline INTERNAL errors were transient backend flakiness — not a docs-repo bug.

The only remaining deterministic failure is fleet-management-api-orgs.py, blocked on the org-membership requirement above (add a roleless member to docs-scheduled-tests). Once that member exists, this PR takes the job fully green.