RSDK-13454: Replace loose_approx with expected_grpc_timeout in tests

[claude]

Summary

• Renamed loose_approx to expected_grpc_timeout across all 22 test files to clearly convey the function's intent
• Replaced relative tolerance (rel=1e-2) with absolute tolerance that models actual grpclib behavior:
  • >10s timeouts: abs=1.01s (~1s from encode_timeout integer-second truncation + ~10ms time_remaining jitter)
  • ≤10s timeouts: abs=0.011s (~1ms from encode_timeout integer-millisecond truncation + ~10ms time_remaining jitter)
• All existing tests pass without any changes to test values

DRI

@ale7714 is the responsible engineer for this PR.

Test plan

• All 371 affected tests pass (136 + 235 across both test runs)
• ruff format passes
• ruff check passes
• No remaining references to loose_approx in tests/

🤖 Generated with Claude Code

[ale7714]

I spend more time learning about this than I should have but the ticket has context https://viam.atlassian.net/browse/RSDK-13454

[claude]

Review: RSDK-13454 — Replace loose_approx with expected_grpc_timeout

Overall this is a solid, well-scoped rename. The new function name is self-documenting, the tolerance values are mathematically correct (verified against grpclib source), and the change is complete — no remaining loose_approx references anywhere in tests/.

Correctness — verified against grpclib source

grpclib.metadata.encode_timeout truncates (not rounds) via int():

timeout range	encoding	max truncation error
> 10s	integer seconds ('{}S')	< 1.0s
0.01–10s	integer milliseconds ('{}m')	< 0.001s

Adding ~10ms of time_remaining() jitter yields:

• abs=1.01 for val > 10 → 1.0 + 0.01 ✓
• abs=0.011 for val ≤ 10 → 0.001 + 0.010 ✓

The boundary val > 10 in expected_grpc_timeout exactly mirrors grpclib's own if timeout > 10 branch. No discrepancy.

Fix applied

tests/test_board.py line 367 contained a pre-existing debug print("timeout is", board.timeout) inside TestClient.test_set_power_mode. This was not introduced by this PR but was left in place. I removed it and pushed the fix directly.

No issues requiring changes-request

• All 22 test files updated; no stale references to loose_approx.
• src/viam/gen/ was not modified.
• No public API surface was changed.
• Format and lint pass cleanly.

[claude]

Code Review

What this PR does

Renames loose_approx → expected_grpc_timeout and replaces the vague 1% relative tolerance with tolerances grounded in grpclib's actual encode_timeout behaviour.

Correctness of the tolerance function

I verified the tolerance values against the real grpclib source (grpclib/metadata.py):

def encode_timeout(timeout: float) -> str:
    if timeout > 10:
        return '{}S'.format(int(timeout))   # integer-second truncation
    elif timeout > 0.01:
        return '{}m'.format(int(timeout * 10**3))  # integer-ms truncation
    ...

The threshold is exactly > 10, matching the PR's if val > 10 branch. The tolerance math is correct:

• >10s path (abs=1.01): int() truncation ≤ 0.999s + ~10ms jitter < 1.01s ✓
• ≤10s path (abs=0.011): int() truncation ≤ 0.999ms + ~10ms jitter < 11ms = 0.011s ✓

Issue fixed in this review

.github/workflows/update_protos.yml (not in PR, required workflow scope to push):
The AI prompt template on line 229 still referenced loose_approx(1.82). When the update-protos workflow runs, the agent would generate new test code calling the removed function, breaking those tests. I committed the fix locally but couldn't push it — the token is missing the workflow scope. This must be merged as a follow-up or the maintainer must push the one-line fix.

The local fix:

-   value1, timeout=loose_approx(1.82), extra={"a": "b"}, metadata={}
+   value1, timeout=expected_grpc_timeout(1.82), extra={"a": "b"}, metadata={}

Minor observation

The new abs=0.011 (11ms) is tighter than the old rel=1e-2 for all test values above 1.1s (e.g. 4.4s → old 44ms vs new 11ms). All 371 tests reportedly passed, and in-process ChannelFor channels incur negligible latency, so this is fine in practice — but worth noting if flakiness appears on a heavily loaded runner.

Everything else looks good

• Rename is complete across all 22 test files — no remaining loose_approx references in tests/
• src/viam/gen/ is not touched
• Debug print statement removed from test_board.py
• expected_grpc_timeout docstring accurately describes the encoding behaviour
• No new abstractions or scope creep

[stuqdog]

This seems reasonable, though it's still just doing an approximation on our side of what gRPC is doing on its side. I'm fine with this merging since it does replace the relative approximation with an absolute one, but @ale7714 I think we had talked about actually using the gRPC methods so that we don't have to approximate at all. Curious if it's worth trying for that still, or if we should just merge this as-is?