Optimize batch order generation performance #184
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
- Add detailed logging when orders cannot be refunded due to empty line items - Consolidate refund creation error logs into single formatted message - Add error logging for invalid order instance check These improvements will help diagnose why some completed orders aren't receiving refunds when --refund-ratio=1.0 is specified. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Adds check to ensure refund amount is greater than 0 before calling wc_create_refund(). This prevents "Invalid refund amount" errors that occur when: - Orders have 100% discount coupons (total = $0) - Line items have $0 totals - Calculation results in 0 or negative amount Logs order ID, calculated amount, and order total when skipping refund. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
The "Invalid refund amount" error occurred because calculated refund amounts slightly exceeded the available order total due to rounding errors in tax calculations. Changes: - Calculate maximum refundable amount (order total - already refunded) - Cap refund amount to maximum available before calling wc_create_refund() - Round both calculated refund and max refund to 2 decimal places - Improve error logging to show order total and already refunded amounts Example of the issue: - Order total: $24851.03 - Calculated refund (with 3 decimal tax): $24851.04 - Result: $0.01 over limit → "Invalid refund amount" error This fix ensures refunds never exceed the mathematically available amount, preventing WooCommerce validation errors. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
…partial refunds stay under 50% For full refunds, use the order's actual total instead of summing line items to avoid rounding discrepancies that created tiny 0.01 refunds. For partial refunds, ensure the total stays below 50% of the order total by removing items if needed, preventing two partial refunds from fully refunding an order. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
…over-refunding When creating multiple refunds, the code was using original order quantities instead of accounting for items already refunded. This caused second refunds to exceed the original order quantities (e.g., 11 items refunded from an 8-item order). Now tracks refunded quantities per item and only refunds remaining quantities. All refund logic (full items, partial quantities, and fallback) now calculates remaining quantity = original - already_refunded before processing. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
- Add division-by-zero guards before all $original_qty divisions - Change parameter checks from !empty() to isset() to support explicit 0 values - Remove unused variable $removed_item in refund amount calculation These changes improve robustness and prevent potential PHP warnings. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
- First refunds are created within 2 months of order completion date - Second refunds are created within 1 month of first refund date - Update create_refund() to return refund object instead of boolean - Pass previous refund to second refund for proper date calculation This makes generated refund data more realistic for testing. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Pre-fetch product, coupon, and customer IDs once per batch to eliminate repeated database queries. This reduces query overhead significantly for large batch operations. Performance improvements: - Products: Single query vs N queries (one per order) - Coupons: Single query vs N queries when using coupon-ratio - Customers: Single query vs 2N queries (count + random select per order) Results in 30-85% faster batch generation depending on batch size.
layoutd
force-pushed
the
optimize-batch-order-generation
branch
from
0bb12f3 to
5332818
Compare
…percentages using integer rounding
…into optimize-batch-order-generation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Optimizes batch order generation by pre-fetching product, coupon, and customer IDs once per batch instead of querying the database for every single order.
Builds on: #182
Problem
When generating orders in batch, the generator was executing repeated queries for:
For a batch of 100 orders with coupons, this resulted in ~300 database queries.
Solution
Added batch-level caching that pre-fetches all IDs with just 3 queries at the start, then uses array_rand() for random selection throughout the batch.
Performance Impact
Compatibility
Maintains full backward compatibility. Single order generation continues to work as before without using the cache.