WooCommerce 11 adds failed-order stock restoration in core. Bundle and composite extensions can reduce stock on a parent, selected components, or both, so an overlapping callback can overstock components or restore a line that was never reduced.
Use this on staging for stores with Product Bundles, Composite Products, mix-and-match kits, custom container products, ERP inventory, reservations, or warehouse synchronization.
Quick answer
Create a bundle with known parent and component quantities, place it on hold so stock is reduced, move it to failed, and record every line before and after. Replay the failure webhook. Pass only when each reduced line returns once, unreduced container lines stay unchanged, and the external inventory ledger agrees.
What to check first
- Record whether the extension manages stock on the container, components, or both for each tested product type.
- Capture order item IDs, container relationships, quantities, stock-reduced flags, callback names, hook priorities, and product stock before the failed transition.
- Test optional components, variable components, backorders, partially unavailable kits, and a quantity greater than one.
- Replay the gateway failure webhook and repeat the failed status action to prove restoration is idempotent.
- Compare the WooCommerce product rows, order notes, reservation layer, ERP export, and warehouse quantities after the test.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
| Map parent and child stock ownership | Record whether the extension manages stock on the container, components, or both for each tested product type. | Parent and child quantities match the pre-order baseline where restoration is expected. |
| Build the product and transition matrix | Capture order item IDs, container relationships, quantities, stock-reduced flags, callback names, hook priorities, and product stock before the failed transition. | Unmanaged container stock does not increase. |
| Capture the first failed transition | Test optional components, variable components, backorders, partially unavailable kits, and a quantity greater than one. | A replay creates no further stock change or duplicate note. |
| Guard overlapping extension callbacks | Replay the gateway failure webhook and repeat the failed status action to prove restoration is idempotent. | ERP, reservation, analytics, and warehouse records match the order ledger. |
Why this usually happens
- Bundle extensions can own component stock separately from the parent line.
- Legacy failed-order callbacks may overlap the new core transition.
- A payment gateway can deliver the same failed event more than once.
- External inventory systems may process the parent and child records at different times.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
order_id: 91042
product_type: bundle
container_stock_managed: false
component_lines: [501x1, 628x2]
stock_reduced_flag: true
failed_transition_runs: 1
webhook_replay_runs: 1
component_delta_after_replay: 0
result: pass
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Map parent and child stock ownership
- Build the product and transition matrix
- Capture the first failed transition
- Guard overlapping extension callbacks
- Replay and reconcile every inventory layer
Decision rule
Pass when each component that was reduced returns exactly once, parent lines that do not manage stock remain unchanged, duplicate events are harmless, and WooCommerce plus external inventory totals reconcile.
What to tell the client or owner
Give the owner the affected versions, exact workflow, observed result, business impact, evidence location, temporary control, named owner, and next review time. Remove credentials and personal data from shared screenshots and logs.
Production verification checklist
- Parent and child quantities match the pre-order baseline where restoration is expected.
- Unmanaged container stock does not increase.
- A replay creates no further stock change or duplicate note.
- ERP, reservation, analytics, and warehouse records match the order ledger.
Mistakes to avoid
- Do not change several plugins, cache rules, or infrastructure settings before preserving a baseline.
- Do not treat one successful test as proof for retries, alternate clients, background work, or mixed-version fleets.
- Do not paste secrets, personal data, complete production payloads, or customer files into tickets or screenshots.
- Do not close the test until the final user-visible state and the server-side evidence agree.
Questions teams ask during testing
Does WooCommerce core understand every bundle extension?
Core checks its stock-reduced state, but extensions can implement product-specific ownership. Test the exact extension and version rather than assuming parent and child behavior.
Should the bundle plugin remove its failed-order hook?
Only after its supported WooCommerce matrix proves the core operation covers the same lines. A version-aware guard is safer during mixed-version support.
When HandL WP should help
Bring in HandL WP when a production checkout, form, email, media pipeline, code-quality gate, or paid lead workflow is at risk. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, connected services, logs, and the user journey.
If this is active on a production site, test WooCommerce bundle inventory restoration.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references