#3325 [Core feature] Task and Workflow state in error reporting Issue created by zeryx Motivation: Why do you think this is important? Currently today the error reporting does not surface where a user error may have occurred within a Task or Workflow in Flyte. This can be very useful with larger scale projects and for debugging difficult to understand surface areas, such as pickle serialization / deserialization between tasks or just understanding which load operation is failing. Goal: What should the final outcome look like, ideally? This feature would provide the Flyte level context as to where a user error is being generated as part of the stack trace. This would ideally include not only just the Task level information, but also the particular workflow. For more complex workflows with map tasks or subworkflows we may want additional reporting such as map element number, etc. It would also be fantastic to provide the raw input objects and variables within the Task that caused the user error to be thrown, to provide additional context for debugging beyond what we have today. Describe alternatives you've considered Alternatives include adding external telemetry such as bugsnag, writing your own error reporting telemetry with console logging, etc. A simple console log at a per task level can provide context, however it's not something we should ever expect our users to need to perform. Beyond that for concurrent tasks and parallel map tasks, it may be difficult if not impossible to line up a console log event with the user error being returned. Propose: Link/Inline OR Additional context No response Are you sure this issue hasn't been raised already? ☑︎ Yes Have you read the Code of Conduct? ☑︎ Yes flyteorg/flyte