Gravity SMTP 2.3.3 improves search fields so fast typing does not lose characters. Debounce timing, slow responses, IME composition, paste, filters, and pagination can still create a race where the visible query differs from the request whose results appear.
Use this for Email Log, Suppressions, and Debug Log searches when support staff cannot reliably find recipients, subjects, provider IDs, errors, or multilingual text.
Quick answer
Create marked records with similar recipients, subjects, provider IDs, Unicode text, and error fragments. Type each target quickly, paste it, use an IME, delete and replace characters, apply filters, and change pages while throttling the network. Record every request query and response order. The input must retain the full final string, stale responses must not overwrite newer results, and URL or filter state must match the rows displayed.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Rapid typing | invoice-10452 | All characters retained |
| IME | Composed recipient | One final query |
| Slow first request | Out-of-order responses | Newest result wins |
| Pagination | Filtered exact query | State stays aligned |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Create marked search fixtures | Record Gravity SMTP version, browser, input method, search surface, fixture strings, debounce interval, request query, response time, page, filters, and result IDs. | No character disappears during rapid typing, paste, replacement, or IME composition. |
| Capture every request query | Test rapid typing, key repeat, paste, select-all replacement, backspace, mobile keyboard, autocomplete, accented text, emoji, CJK composition, and right-to-left input. | Responses for old queries cannot replace results for the current input. |
| Force out-of-order responses | Throttle requests so an early broad query returns after a later exact query, then verify the later query still owns the displayed rows and count. | Filters, pagination, URL state, counts, and visible rows remain synchronized. |
| Test IME and mobile input | Combine search with date, status, provider, source, pagination, rows-per-page, browser back, refresh, and two open tabs. | Email Log, Suppressions, and Debug Log searches behave consistently across supported browsers. |
What to check first
- Record Gravity SMTP version, browser, input method, search surface, fixture strings, debounce interval, request query, response time, page, filters, and result IDs.
- Test rapid typing, key repeat, paste, select-all replacement, backspace, mobile keyboard, autocomplete, accented text, emoji, CJK composition, and right-to-left input.
- Throttle requests so an early broad query returns after a later exact query, then verify the later query still owns the displayed rows and count.
- Combine search with date, status, provider, source, pagination, rows-per-page, browser back, refresh, and two open tabs.
- Confirm search values do not expose recipient addresses or message content in logs, analytics, referrers, or shared screenshots beyond the approved evidence.
Field notes
- Write the pass condition before changing anything. A repeatable synthetic fixture makes the before and after comparison useful.
- Keep exact versions and UTC timestamps because scheduled jobs, caches, retries, and background processing can change the evidence.
- Check the public experience and the stored server-side result. Admin previews and isolated API calls do not prove the whole workflow.
- Repeat the test after the relevant cache, queue, scheduled action, webhook, and observation window has finished.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
search_trace:
surface: email-log
input_sequence: [i, in, inv, invoice-10452]
final_query: invoice-10452
response_order: [4, 2, 3, 1]
displayed_owner: 4
Why this usually happens
- A controlled input value is replaced by a stale state update after each request.
- A debounce handler closes over an earlier string or is recreated on every render.
- The request layer does not cancel or ignore responses for superseded queries.
- IME composition events are treated as complete key input before the user commits the text.
Decision rule
Pass only when the complete final input, active filters, URL state, result rows, count, and newest request ID agree under fast typing and out-of-order responses.
Production verification checklist
- No character disappears during rapid typing, paste, replacement, or IME composition.
- Responses for old queries cannot replace results for the current input.
- Filters, pagination, URL state, counts, and visible rows remain synchronized.
- Email Log, Suppressions, and Debug Log searches behave consistently across supported browsers.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Create marked search fixtures
- Capture every request query
- Force out-of-order responses
- Test IME and mobile input
- Verify final state ownership
Mistakes to avoid
- Changing production before recording exact versions, UTC time, the affected fixture, current behavior, and a tested rollback point.
- Accepting one successful admin screen while the stored record, API response, queue, email, browser, or downstream system remains unchecked.
- Testing only as an administrator instead of the role, browser, locale, network state, catalog size, and failure path a real user reaches.
- Leaving broad credentials, debug logs, temporary filters, synthetic records, or recovery code active after verification.
Questions teams ask during testing
Should I test this on production?
Use production for read-only evidence first. Reproduce the change on staging with current data, extensions, cache, browser mix, and integration settings. If a production canary is necessary, make it reversible, identifiable, monitored, and unable to charge a customer or expose personal data.
How do I rule out a cache artifact?
Record the origin response, purge only affected paths, and repeat in private and normal sessions. Compare stored data and server logs with the visible page. A cache hit is useful evidence only when you know which version and settings it contains.
What belongs in the evidence packet?
Keep UTC time, exact versions, fixture ID, role, browser, expected result, actual result, relevant response or log lines, change made, rollback point, owner, and final verification. Redact passwords, tokens, personal data, and private URLs.
When is the test complete?
Close it when the main path and important failure branches pass, records reconcile across systems, accessibility and mobile checks are complete, temporary changes are removed, and monitoring covers the next update or business cycle.
What to tell the client or owner
Give the owner a short packet with the affected workflow, exact versions, UTC test time, fixture ID, expected result, actual result, key evidence, change made, rollback point, unresolved risk, owner, and next review date. Remove credentials and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP test an SMTP admin regression.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references