We’re encountering partial transaction failures in the material management API when processing batch inventory operations. When one operation in a multi-step inventory transaction fails (due to insufficient quantity, invalid lot numbers, or location constraints), the previously completed steps don’t roll back, leaving inventory in an inconsistent state.
Example scenario: Batch operation issues 5 materials from warehouse to production line. If material #3 fails due to insufficient quantity, materials #1 and #2 remain issued but the transaction is marked failed. We need saga pattern implementation with compensating transactions to undo partial operations.
Current API calls:
POST /api/v1/inventory/batch-issue
{"materials": [{"id": "MAT-001", "qty": 100}, ...]}
Response: 500 Internal Server Error (partial data committed)
Looking for guidance on implementing dry-run validation before actual transactions and using idempotency keys to prevent duplicate operations during retries. How should atomic inventory transactions be handled in FT 11.0?
Don’t overlook the importance of proper error handling in your compensating transactions. When you need to reverse a partial batch operation, the reversal itself might fail (e.g., can’t return material to a location that’s now full). Your saga implementation needs compensating transaction logic that handles failures in the compensation steps too. We maintain a compensation queue with manual review for scenarios where automated rollback isn’t possible.
This is a fundamental limitation in FT 11.0’s material management API - it doesn’t support true atomic transactions across multiple inventory operations. Each material issue in your batch is committed independently, so when operation #3 fails, operations #1 and #2 are already persisted. You need to implement application-level transaction management using the saga pattern with explicit compensating transactions to reverse successful operations when later steps fail.
Good point about dry-run validation. Does the validate-batch endpoint check the same constraints as the actual batch-issue operation? Also, what about race conditions - could inventory quantities change between validation and actual execution, causing the real operation to fail even though validation passed?