Gravity SMTP 2.3.3 fixes the integration test tool so removed integrations no longer remain available in the Send With selector. A stale browser tab, object cache, saved option, direct request, scheduled retry, or custom integration can still reference the old connector ID after the visible card is gone.
Use this after removing, replacing, renaming, or disconnecting an SMTP integration, especially when test mail or queued messages still appear to use the old provider.
Quick answer
Record the connector ID and all current references before removal. Remove the marked test connector on staging, then inspect the Send With selector in a fresh and stale tab, the saved settings response, object cache, direct test request, routing rules, queued jobs, and backup connector. The old ID must be rejected server-side, not merely hidden in JavaScript, while existing logs remain readable and new mail chooses an active allowed connector.
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 |
|---|
| Fresh tab | Removed connector | Absent from selector |
| Stale tab | Old option selected | Server rejects ID |
| Queued retry | Historical connector ref | Documented safe result |
| New message | Routing rule | Active connector only |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Inventory connector references | Record connector ID, provider, active state, primary and backup roles, routing rules, test-tool options, saved settings, scheduled jobs, and open admin tabs. | The removed connector is absent from current test, route, primary, and backup selectors. |
| Remove one marked connector | Remove a marked connector, then compare a fresh page, stale tab, private browser, another administrator, translated dashboard, and cleared object cache. | A stale tab or direct request cannot send through the removed connector ID. |
| Test fresh and stale clients | Submit a direct test request containing the removed ID and verify capability, nonce, connector existence, and active-state checks reject it safely. | Queued work created before removal has a clear fail, reroute, or cancellation record. |
| Reject direct stale IDs | Run a queued retry created before removal and document whether it fails, reroutes, or resolves through a durable provider reference. | Historical email logs remain readable and new messages use one active connector. |
What to check first
- Record connector ID, provider, active state, primary and backup roles, routing rules, test-tool options, saved settings, scheduled jobs, and open admin tabs.
- Remove a marked connector, then compare a fresh page, stale tab, private browser, another administrator, translated dashboard, and cleared object cache.
- Submit a direct test request containing the removed ID and verify capability, nonce, connector existence, and active-state checks reject it safely.
- Run a queued retry created before removal and document whether it fails, reroutes, or resolves through a durable provider reference.
- Preserve historical email logs and provider IDs while confirming no new message can select the removed connector.
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.
removed_connector_test:
connector_id: smtp-test-old
removed_at: 2026-09-09T09:25:00Z
ui_option_present: false
direct_request_allowed: false
queued_retry_result: record-result
Why this usually happens
- The integration card is deleted but an option cache still returns its identifier.
- A stale tab submits a connector ID that was valid when the page loaded.
- A scheduled job stores a provider reference rather than resolving the current route at send time.
- A custom integration reports itself active after its credentials or settings were removed.
Decision rule
Removal is complete when every new UI and server path rejects the old ID, queued work has an explicit outcome, and active connectors continue sending without rewriting historical logs.
Production verification checklist
- The removed connector is absent from current test, route, primary, and backup selectors.
- A stale tab or direct request cannot send through the removed connector ID.
- Queued work created before removal has a clear fail, reroute, or cancellation record.
- Historical email logs remain readable and new messages use one active connector.
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.
- Inventory connector references
- Remove one marked connector
- Test fresh and stale clients
- Reject direct stale IDs
- Resolve queued retry 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 clean up an SMTP connector.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references