# Visitor connection recovery

Deliver live visitor updates to the relevant browser page and retain selected pending actions while it connects.

*Release 3.3 · developer, visitor*

## What it is

INSIDE sends live visitor updates to the relevant open browser connection. Some actions can wait until the matching page connects. This supports normal visitor interaction when page tracking and the live connection become ready at different times.

## Who uses it and why

Developers need to understand which page receives an action when integrating INSIDE into a website. Visitors benefit from live chat and engagement controls updating as their connection becomes available.

## Where to find it

This behaviour operates within the website's INSIDE visitor experience. It has no separate Settings page or visitor recovery control.

## How it works

INSIDE can send a live update to all of a visitor's connections, one eligible connection or the connection associated with a particular page view. Multiple open pages can therefore receive different updates.

For selected actions, INSIDE keeps a pending action if the target connection is not available. When a page connection registers, INSIDE sends the pending actions for that page and eligible visitor-wide actions. Ordinary pending actions are then removed from the waiting list.

Some continuing actions remain available to later connections until they are explicitly cleared. This limited buffering does not cover every live update.

## Configure it

Use the website's supported INSIDE integration to establish the visitor connection and process its updates. There is no client setting for a general replay window in this release.

When investigating an interruption, record whether it affected one tab, several tabs or a page navigation. Ask Powerfront to check the relevant visitor interaction if an action fails to appear after reconnection.

## Limits and good to know

- Recovery of a live connection does not guarantee replay of every update sent during an interruption.
- Pending actions are temporary live state. Do not rely on them surviving a service restart.
- An action intended for one page is not automatically applicable to the visitor's next page.
- Connection status alone does not establish whether a conversation message was delivered. Use the conversation's delivery status where available.

## Depends on and works with

### This feature uses

- **Requires** [Visitor activity and availability](VIS-011.md): Live visitor connections determine where updates can be sent.
- **Works better with** [Visitor identity](VIS-001.md): Visitor recognition supports continuity when a browser reconnects.
- **Works better with** [Visitor page and product tracking](VIS-003.md): Tracked page views let selected live updates be targeted and buffered for a particular page.
- **Works better with** [Time-based visitor event triggers](VIS-026.md): Selected time-on-page registrations can wait for the matching page connection.
- **Related** [Message delivery and read receipts](CHAT-003.md): Check message delivery feedback separately when deciding whether to resend after a connection interruption.

### Used by

- **Required by** [INSIDE visitor CLI](VIS-024.md): The test visitor receives updates through the existing live visitor connection.
- **Required by** [Time-based visitor event triggers](VIS-026.md): Time On Page registration and completion use the visitor's browser connection.
- **Required by** [Visitor chat status and waiting](VX-007.md): Live updates carry availability and conversation state.

## FAQ and troubleshooting

### Will every missed update be replayed after reconnection?

No. Only selected actions use pending-action handling in this release.

### Why did an action appear in one tab only?

Some actions target a specific tracked page or one visitor connection.

### Can I set a guaranteed recovery period?

There is no client-configurable general replay period for this behaviour in 3.3.

### Should I resend a chat message just because the connection dropped?

Check the conversation and its delivery feedback first. Connection recovery and message delivery are separate behaviours.