v1.3.4

Bug Fix

StepError now returns 500 to trigger Inngest retry mechanism

Previously, when a step threw an exception, the SDK wrapped it in StepInterruptException with StepOpCode.StepError and returned HTTP 206. Inngest interpreted 206 as "steps need scheduling" but couldn't handle StepError as a schedulable operation.

Changes

• InngestClient now checks for StepError in StepInterruptException and returns HTTP 500 with proper error format to trigger retries
• StepTools.Run now re-throws NonRetriableException and RetryAfterException instead of wrapping them, so they're handled by dedicated catch blocks
• Added comprehensive tests for step error scenarios
• Added example functions demonstrating error handling patterns

Behavior Summary

Exception Type	HTTP Status	X-Inngest-No-Retry	Retry-After
Regular step error	500	false	-
NonRetriableException	400	true	-
RetryAfterException	500	false	{seconds}

Full Changelog: v1.3.3...v1.3.4