TeraWallet 1.6.8 — REST admin writes fatal (WooWallet_Idempotency not loaded)
- 2 posts
- 2 voices
- Reply
Conversation
3 posts · 2 voices-
July 20, 2026 at 3:46 pm #9369
TeraWallet 1.6.8 — REST admin writes fatal (WooWallet_Idempotency not loaded) + idempotent replay returns 500 for a completed transaction
Environment: TeraWallet 1.6.8 (official package), WordPress 7.0.2, WooCommerce 10.9.4, PHP 8.2.29, authentication via application password (Basic auth) with a user having wallet admin capabilities.
Bug 1 — critical: every terawallet/v1 admin write returns 500 (class not found).
Any authenticated write request, e.g.:
POST /wp-json/terawallet/v1/admin/transactions
Idempotency-Key: example-123
{“user_id”: 32, “type”: “debit”, “amount”: 0.04, “note”: “test”}returns 500 internal_server_error (WordPress “critical error” page as body). Cause: the controllers call WooWallet_Idempotency::run() (e.g. in includes/api/v1/admin/class-terawallet-rest-admin-transactions-controller.php, create_item), and the class file ships at includes/services/class-woo-wallet-idempotency.php, but nothing loads it — class_exists(‘WooWallet_Idempotency’) is false at runtime, and there’s no include/autoload entry for it in includes/class-woo-wallet.php or elsewhere. This makes admin/transactions (create), admin/users/{id}/transactions/purge, and every other path calling require_idempotency_key()+run() fatal for all 1.6.8 installs.
Workaround we applied: adding
include_once WOO_WALLET_ABSPATH . ‘includes/services/class-woo-wallet-idempotency.php’;
next to the other includes in includes/class-woo-wallet.php restores the endpoints. Please add the include (or autoloader entry) in the next release.Bug 2 — idempotency replay of a completed transaction returns 500 instead of the stored result.
Sequence observed (after applying the workaround above):
POST /admin/transactions (debit, Idempotency-Key: billing-sync-122-270). Server-side the transaction completed (wallet balance moved, transaction recorded), but our client hit its HTTP timeout before the response arrived (the request also sends the customer email synchronously, which can push response time past short client timeouts).
Retried the identical request with the same Idempotency-Key, expecting the recorded transaction back per idempotency semantics.
Response: 500 {“code”:”terawallet_rest_transaction_failed”,”message”:”Wallet transaction could not be recorded.”}.
The good news: no double charge happened. But the replay should return the originally recorded transaction (200) rather than re-running the closure and failing — otherwise API clients must treat a successfully completed charge as a failure, which defeats the purpose of the Idempotency-Key header. It looks like the stored-response persistence may not survive a client disconnect, so the replay re-executes and then the duplicate guard makes woo_wallet()->wallet->debit() return false.Happy to provide logs or test anything on our staging site. Thanks for the plugin — the new terawallet/v1 API (idempotency included) is a clear step up from the wc/v2 routes once these two issues are sorted.
-
July 20, 2026 at 4:24 pm #9370
extra findings — updating to 1.6.8 via the WP updater leaves the install broken until a manual reactivation.
wp_woo_wallet_idempotency table is MISSING, and a direct wallet->debit() returns false with no SQL error. The TeraWallet 1.6.8 update’s database upgrade never ran — its new tables weren’t created — so every debit fails. -
Thanks for the detail — I dug into this and want to correct one thing before you spend more time on it.
There is no woo_wallet_idempotency table in 1.6.8 or any other version. Idempotency keys are stored as WordPress transients, not in a table, so a missing table isn’t the problem. TeraWallet only ever creates three tables: woo_wallet_transactions, woo_wallet_transaction_meta, and woo_wallet_referrals.
1.6.8 contained no database changes at all — it was a locale/translation fix release. The last version with a schema migration was 1.6.4, so there was no upgrade for 1.6.8 to run and nothing that reactivation would create.Migrations aren’t tied to activation. The upgrade routine runs on every page load, comparing the woo_wallet_db_version option against the plugin version. You can confirm on the affected site with wp option get woo_wallet_db_version — it should match the installed plugin version. If it does, the upgrade path has run.
debit() returning false with no SQL error is expected behaviour, not a symptom of a missing table — a missing table would raise a $wpdb error. It returns false silently in five cases: no user ID, the wallet account is locked, the row lock timed out, the ledger balance is insufficient, or the insert failed. In practice, it’s almost always a locked account or insufficient balance. Worth checking:
is_wallet_account_locked( $user_id ); // expect false woo_wallet()->wallet->get_wallet_balance( $user_id, 'edit' ); // vs the debit amountOne caution if you use the credit-expiry add-on: the debit gate checks the raw ledger total, while the displayed balance is the filtered post-expiry figure. The two legitimately differ, so compare against the raw total when diagnosing.
That said, 1.6.8 does have a real bug that matches your symptoms — just a different one. Every REST API write endpoint (terawallet/v1/admin/transactions, transaction purge, transfers error) is affected because a required class was never loaded. If your integration creates debits over the REST API, that’s very likely what you hit, and a client that treats a 500 as a failed debit would report exactly what you’re seeing.
This is fixed in 1.6.9 and will be published at the end of this week, along with a related issue where retrying could report a completed transaction as failed — or, with sufficient balance, charge twice. I’d recommend updating rather than pursuing the table theory. If debits still fail after 1.6.9, send the output of the two calls above, and I’ll take another look.
Post a reply
Paste the exact error, your WooCommerce + WordPress versions, and any relevant steps. Screenshots help.
You must be logged in to reply to this topic.
Still stuck?
Three fast ways to keep moving if the thread above didn't resolve it.
