travisninja22

Hi Lucián,

Thanks again for the earlier guidance. Here’s a full follow-up.

How we authenticate (custom Ice Cream OTP Auth 1.0.6)
On OTP success (signup or login): wp_insert_user when it’s a new account, then wp_set_current_user, destroy session tokens, wp_set_auth_cookie, update_user_meta for last_login, then redirect. We do not call <code class=””>do_action( ‘wp_login’ ) on that path.

Your questions (recap)
The ~47 users with no WSAL rows were a mix of dormant and active users; we used last_login to confirm the OTP path had run (set at both registration and login for our flows).

Object caching
We don’t have a definite answer yet: no obvious Redis/Memcached plugin in wp-admin; there may still be host-level object cache—we can confirm with the host and update you.

Shutdown / buffer test
Per your suggestion we temporarily set <code class=””>define( ‘ICS_OTP_WSAL_FLUSH_TEST’, true ); in wp-config.php while the OTP plugin called <code class=””>wp_ob_end_flush_all() immediately before post-login redirects (OTP signup, OTP login, password-reset auto-login, account recovery). That constant has been removed from wp-config.php again after the test (flush off in production unless you want it back on).

Other plugin (transparency)
“IceCream Access Cookie” hooks set_logged_in_cookie to set a separate ics_access cookie and uses a very late <code class=””>shutdown callback for optional Hola HTML caching. We don’t think it blocks WSAL, but we can disable it for isolation if you want.

Controlled retest — 4 Feb 2026 (local time = WSAL UI)
Six manual OTP runs with the flush test on. Every run logged the expected signup chain: 6061 → 4000 → 1000 → 2101. Five of six also went through a second round (logout → OTP sign-in), and those showed 6061 → 1000 → 2101 again. No missing events in what we captured.

1. espanoltravis@gmail.com (~9:51–9:54 pm)
2. englishtravishawaii@gmail.com (~10:15–10:17 pm)
3. bduncan2171@gmail.com (~10:19–10:24 pm)
4. bduncan2171@outlook.com (~10:26–10:35 pm)
5. spanishtravishawaii@gmail.com (~10:51–10:54 pm)
6. icecreamspanish@icloud.com (~10:58–11:00 pm) — same full signup chain in WSAL; our export for this address did not include a second logout + OTP sign-in block like the other five (not that OTP was skipped for signup).

Historical ~45% gaps vs this test
The old missing rows line up with real Facebook ad traffic; these six were quiet, manual tests. So load / device / funnel / timing may still matter in production, even though this controlled sample was fully logged.

SQL (optional check)
<code class=””>SELECT username, COUNT(*) … FROM wp_wsal_occurrences for those six emails: all > 0 rows. Totals are inflated because we reused and deleted several of those addresses many times over time—not one session per count.

Ask
Given flush + 0 misses in this sample, does that fit your shutdown-timing theory for the older misses? Does WSAL 5.6.x document a recommended pattern (buffers, hook priority, deferring redirect) or any internal/debug way to confirm events are queued before the request ends?

Thanks,
Travis