Check for grpc status details before indexing & unpacking

[THardy98]

DWISOTT, fixes bug

1. Closes [Bug] We assume an element is present in an error details list #791

2. How was this tested:
   Added small integration test, mock RPC error using an interceptor.

3. Any docs updates needed?
   No

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[dandavison]

I'm seeing this test pass with the changes to temporalio/client.py reverted.

uv run pytest -s tests/worker/test_update_with_start.py::test_start_update_with_start_empty_details_interceptor

Is what I'm running.

[THardy98]

Agh - the interceptor raises an error before we make any calls or run any handlers... so we're testing nothing but the test code 🤦

I've replaced this by instead mocking the workflow service call. It does indeed fail without the details check.

[dandavison]

Nice! Maybe this is a nit but did you look into making it not print out the exception below? I find that irrelevant stack traces are one of the main things that make it hard to understand CI logs, so it would be nice if we could avoid it.

tests/worker/test_update_with_start.py .

================================================================================================= 1 passed in 0.54s ==================================================================================================
Future exception was never retrieved
future: <Future finished exception=RPCError('empty details')>
Traceback (most recent call last):
  File "/Users/dan/src/temporalio/sdk-python/tests/worker/test_update_with_start.py", line 843, in test_start_update_with_start_empty_details
    await client.start_update_with_start_workflow(
  File "/Users/dan/src/temporalio/sdk-python/temporalio/client.py", line 1048, in start_update_with_start_workflow
    return await self._start_update_with_start(
  File "/Users/dan/src/temporalio/sdk-python/temporalio/client.py", line 1120, in _start_update_with_start
    return await self._impl.start_update_with_start_workflow(input)
  File "/Users/dan/src/temporalio/sdk-python/temporalio/client.py", line 6113, in start_update_with_start_workflow
    raise err
  File "/Users/dan/src/temporalio/sdk-python/temporalio/client.py", line 6059, in start_update_with_start_workflow
    return await self._start_workflow_update_with_start(
  File "/Users/dan/src/temporalio/sdk-python/temporalio/client.py", line 6149, in _start_workflow_update_with_start
    await self._client.workflow_service.execute_multi_operation(multiop_req)
  File "/Users/dan/src/temporalio/sdk-python/tests/worker/test_update_with_start.py", line 836, in __call__
    raise self.empty_details_err
temporalio.service.RPCError: empty details

[THardy98]

I spent a bit of time, but was satisfied when poe test didn't produce this - only when running the single test, but I'll take another look

[THardy98]

can't seem to fix this, but that's probably my lack of Python speaking
we await the update call so I'm not sure where the future is coming from, and my understanding was that pytest.raises catches expected errors raised from the code block nested within it, so double misunderstanding for me

@cretz my feeling is that this is something that could be fixed easily, if it isn't, any opposition to just suppressing the warning?
I'd rather not spend more time mentally walking in circles

[dandavison]

OK, no worries! It wasn't obvious to me either. Definitely not blocking.

[dandavison]

Ah, that said, I think I've got a solution. This was helpful:

    loop = asyncio.get_event_loop()
    loop.set_debug(True)

#804