Add __enhanced_stack_trace query to workers #537
Conversation
|
|
|
Divyank Jain seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
added query to workflow internals, created integration test and modified query error integration test to account for new default query.
|
Will get to adding an external test for |
tests/worker/test_workflow.py
Outdated
| for source in trace["sources"].keys(): | ||
| if source.endswith("externalstacktrace.py 53"): | ||
| fn = source |
There was a problem hiding this comment.
So the thing I was kind of interested to see work is that a workflow defined in one file loading code from another file would properly show both files in the sources.
So, I don't know if you need to copy the whole workflow to the externalstacktrace file, but rather just run a coroutine that imports some code from it.
There was a problem hiding this comment.
gotcha, I'll probably create another file to avoid a circular dependency for it then.
| @@ -1791,6 +1800,42 @@ def _stack_trace(self) -> str: | |||
| ) | |||
| return "\n\n".join(stacks) | |||
|
|
|||
| def _enhanced_stack_trace(self) -> temporalio.common._EnhancedStackTrace: | |||
There was a problem hiding this comment.
Can you give an idea of what this full string looks like for a simple workflow (or what it looks like in the test cases)/ My concern is that Python stack traces are pretty poor and so we'd be showing a lot of source lines for our code instead of user code.
There was a problem hiding this comment.
To clarify, even just showing us what this may look like here in GH comments can help us understand how good/bad the Python stack traces may be. I recall they are pretty bad for many users.
There was a problem hiding this comment.
stack_trace.txt
This is the test output for a __stack_trace call, for reference!
There was a problem hiding this comment.
Thanks! Yeah that does a good job of showing the current poor state of Python stack traces. We'll confer as a team to see what we can do here (and if we want enhanced to wait on that).
|
Writing down for myself -- ensure that |
…nal_enhanced_stack_trace` to work with redefinitions, will try to mark `test_workflow_external_multifile_enhanced_stack_trace` as a test to skip until we find a way to deterministically get those results. (I really have to rename these tests)
|
@twin-drill - CI is failing for a known issue after CLI release. I will make a PR soon to fix it. |
… set to 0. Update tests to account for this, made them more specific while I was at it.
…issue in importlib
What was changed
Added a new query,
__enhanced_stack_trace, to workers. This query builds upon the pre-existing__stack_tracequery to provide mappings of code where each worker is currently suspended/working.Added integration test:
test_workflow_enhanced_stack_trace, with similar tests to those intest_workflow_stack_trace; adjustedtest_workflow_signal_and_query_errorsto account for new default queries in workers.How was this tested:
Integration tests were run, locally passing (using Temporalite and Temporal dev server)