Perspective sessions stop updating after an identity-provider token expires, while the Gateway web page may sleep and require authentication when resumed. The Designer can remain connected because it is not a browser and does not necessarily share the browser session lifecycle. Treat the persistent Designer connection as a separate path, not proof that browser authentication is healthy. An expired token should terminate the authenticated browser path.
Which data path stops carrying requests?
Follow the packet from the component displaying stale data. A Perspective browser session sends requests through the browser network stack to the Gateway, which associates those requests with an authenticated web session. Authentication redirects or token exchanges also involve the identity provider. The Designer uses its own nonbrowser connection and session bookkeeping.
| Client | Request path | Observed symptom | First proof |
|---|---|---|---|
| Perspective session | Browser → network → Gateway | Displayed data stops updating | Inspect browser requests at the time updates stop |
| Gateway web page | Browser → network → Gateway | Sleeping tab requires authentication when resumed | Compare the last successful request with the first request after resume |
| Designer | Nonbrowser client → network → Gateway | Connection remains active | Confirm the Designer can perform a fresh Gateway operation, not merely display cached state |
| Identity provider | Browser authentication exchange | Token expires or authentication restarts | Match browser authentication events to identity-provider and Gateway logs |
Record one timestamp for the last successful Perspective update, one for the first failed or redirected request, and one for any authentication event. The path is identified when those records describe the same transition.
Does the physical connection fail before authentication?
Layer one first. A token problem and a transport interruption can produce the same operator symptom: no new values arrive. Prove that the client still has a usable network path before interpreting redirects, session state, or identity-provider behavior.
- At the affected browser workstation, confirm that the network interface remains connected when data stops updating.
- Test whether the Gateway address remains reachable through the same route used by the browser.
- Check for interface resets, address changes, name-resolution changes, wireless roaming, or a proxy or firewall closing an idle connection.
- In browser developer tools, determine whether requests are still sent. Separate requests with no response from responses that redirect, reject authentication, or return a web page instead of application data.
- Repeat the observation across an active tab and a tab allowed to sleep. This distinguishes loss during continuous traffic from loss associated with suspension or idle time.
| Observation | Likely stopping point | Next check |
|---|---|---|
| No request leaves the browser | Tab suspension or client application state | Inspect browser lifecycle and console events |
| Request leaves but no response returns | Network path or intermediary | Inspect transport errors and network-device logs |
| Gateway returns an authentication response | Gateway session or token validation | Correlate the response with Gateway and identity-provider logs |
| Successful responses continue but values remain stale | Perspective update path | Inspect the response content and session diagnostics |
The physical and transport layers pass when a fresh browser request reaches the Gateway and receives a response during the failure.
What does the browser do when the token expires?
The browser owns tab lifecycle, cookies, redirects, and browser-visible authentication state. A sleeping tab may suspend application timers or network activity. When the tab resumes, its next request can expose an already expired token or server-side session. That makes resume the point where the failure becomes visible, not necessarily the point where expiration occurred.
- Open the browser network recorder before starting the test and preserve the request history across navigation.
- Keep one Perspective session active while placing another comparable session in the background or allowing it to sleep.
- For each session, mark the last successful data request and the first request made after inactivity.
- Inspect the first failing response for an authentication redirect, rejection, connection error, or unexpected HTML response.
- Compare that timestamp with the identity-provider token-expiration record and any new authentication transaction.
Do not convert “data stopped” directly into “token expired.” The deciding evidence is the first failed request and the corresponding authentication record. The browser side is proven when the failure reproduces at a token or session transition while basic Gateway reachability remains intact.
Where does Gateway session bookkeeping break the update path?
The Gateway must map each incoming browser request to an authenticated session. If that association expires, becomes invalid, or is not renewed, the request can no longer continue as authenticated application traffic. The visible result may be a login transition, rejected request, or silent loss of Perspective updates, depending on how the browser handles the response.
Version matters during diagnosis. The reported candidates are 8.1 and 8.3, and 8.3 has significant changes to Designer and Vision client session bookkeeping on the Gateway. Record the actual version before comparing browser and Designer behavior.
| Item to record | Why it matters | Proof source |
|---|---|---|
Gateway version: 8.1 or 8.3
|
Session bookkeeping differs across these version lines | Gateway system information |
| Browser session identifier | Connects requests before and after the failure | Browser request details and Gateway diagnostics |
| Token expiration event | Defines when authentication validity ends | Identity-provider record or decoded token field exposed by the configured system |
| First rejected or redirected request | Locates the actual break | Browser network trace and Gateway log |
Correlate these records by timestamp and session. Gateway session handling is the stopping point when the network request arrives, the Gateway no longer accepts its authenticated association, and the identity-provider record explains why.
Why can Designer remain connected?
The Designer is not a browser. It does not use browser tab suspension, and its connection can follow different session bookkeeping from Perspective and Gateway web pages. Therefore, a live Designer connection and a failed browser session are not contradictory.
Also distinguish an existing connection from a new authentication decision. A client can appear connected because its established session is still recognized, while a browser making a fresh request must present valid session state. The engineering question is whether Designer persistence is intended for the installed version and configuration, not whether it matches browser behavior.
- When the browser fails, perform a fresh authenticated operation from Designer that requires Gateway communication.
- Record the Designer session in Gateway diagnostics and compare its creation and activity times with the browser session.
- Disconnect Designer, then test a new connection. Do not treat successful traffic on an old connection as proof that new authentication succeeds.
- Compare the result on the actual Gateway version, paying particular attention to the session-bookkeeping changes associated with
8.3.
The paths are proven separate when the browser request fails authentication while a fresh Designer operation still reaches the Gateway through its own recognized session.
How do you verify the complete fix?
Correct the component identified by the trace: physical path, browser lifecycle, Gateway session handling, or identity-provider renewal. Avoid masking the fault with manual refresh alone; refresh starts a new request or authentication flow but does not explain why the established path stopped.
- Start a new Perspective browser session and record its browser session reference, Gateway session reference, and authentication start time.
- Confirm live data changes arrive before the expected expiration boundary reported by the configured identity provider.
- Keep one tab active and subject a second tab to the same sleep or inactivity condition that previously triggered the symptom.
- Observe both sessions through token expiration and resume. Check that the browser either renews authentication through the configured flow or visibly disconnects and requests authentication.
- Verify that no session remains silently authenticated after its token is invalid and that Perspective data does not remain frozen behind an apparently connected display.
- Repeat the test with Designer connected, then reconnect Designer to distinguish retained session state from fresh authentication.
The fix passes when browser, Gateway, and identity-provider records agree on the transition and the operator sees either continuing authenticated updates or an explicit authentication request.
FAQ
What happens if a Perspective token expires while the tab is asleep?
The tab may reveal the expiration only when it resumes and sends its next request. Capture that request and verify whether the Gateway redirects or rejects it, then match the timestamp to the identity-provider record.
What happens if Perspective data stops but the Gateway still responds?
Inspect the response rather than treating reachability as application health. An authentication response, redirect, or unexpected HTML page places the break in session handling; successful data responses place it in the Perspective update path.
What happens if Designer stays connected after the browser token expires?
Designer uses a nonbrowser connection and may have different Gateway session bookkeeping, particularly when comparing 8.1 with 8.3. Disconnect and reconnect Designer, then confirm that the new operation and the browser transition both appear correctly in Gateway authentication diagnostics.