Reapply complete Axis event filters after a WebSocket reconnect

Bottom line: Treat an Axis event WebSocket reconnect as a fresh subscription setup and preserve the complete intended filter outside the session.

Source fact: documented behavior

The Event streaming over WebSocket documentation says each connection is a separate session that ends when the connection terminates.

Those sessions are stateless and cannot continue after connection termination.

Sending a new configuration request updates the event filter, and only the latest filter applies.

What the source does not establish

Do not infer automatic subscription recovery or recovery of missed events from a new WebSocket connection alone. Keep this application-session behavior separate from the underlying opening handshake. Require support for the documented endpoint and authentication on the actual device. Treat the proposed reconnection logic as integration work to test, rather than a guarantee made by this article.

Applicability questions

• Where does the integration retain its complete intended event filter?
• Which component sends and verifies subscription configuration after reconnecting?
• Does a filter update contain the full desired selection or only an assumed addition?
• How will operators recognize an interval when event coverage has not been established?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends making subscription configuration a deliberate state in the client’s reconnection workflow.

1. Write the intended event selection as configuration owned by the integration, with an identifiable revision. Separate connection establishment, filter configuration and representative event receipt in the test plan. Avoid an implementation that treats an open socket as the final healthy state. Define how the client reports an unsuccessful configuration response before it labels the event path ready.
2. Use proposed test topics A and B as labeled placeholders for real supported events. Begin with a complete A-and-B filter, then apply a deliberately different complete selection and observe the intended change. Compare the request, response and received events. Review any code that sends only the newly desired portion as if previous filter entries necessarily remain active.
3. In an authorized pilot, interrupt and restore the test connection through a supported method. Have the client establish the new session, send its complete intended configuration and verify the required events. Preserve the uncertain interval in monitoring evidence. If the business requirement needs additional continuity or reconciliation, ask the integration owner to design and verify it separately.

Verification and evidence

Retain the device/software identity, supported interface reference, filter revision, sanitized configuration requests and responses, connection timestamps and marked event inputs. Record the moment at which the client declares the subscription ready and what evidence justifies that declaration.

Include a rejected-configuration case and a reconnect case in the proposed acceptance exercise. Ask an operator to distinguish socket availability from verified event coverage and to follow the documented escalation for an unresolved gap. This article reports no completed connection test, recovered event backlog or end-to-end delivery guarantee.

Official references

• Event streaming over WebSocket — Axis Communications; official VAPIX documentation.

Source review completed October 28, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.