lseg-data (RTO) 2.1.1: "Session is not opened" on Azure Linux Web Apps

HenryI

We’re seeing the following error from lseg-data 2.1.1 (Python 3.11) when calling ld.get_data(...):

First observed: 16 Jan 2026 (UTC).
We’re confident this flow worked prior to the week commencing 5 Jan 2026.

Error
ValueError: Session is not opened. Can't send any request
File "/usr/local/lib/python3.11/site-packages/lseg/data/_access_layer/get_data_func.py", line 61, in get_data
raise_if_closed(session)
File "/usr/local/lib/python3.11/site-packages/lseg/data/_core/session/tools.py", line 36, in raise_if_closed
raise ValueError(error_message)

Environment / how we reproduce

Azure Linux Web App (App Service) running a custom container

Same container image + same code; we switch only the App Service Plan SKU

Basic (B2/B3): consistently fails with “Session is not opened” (but worked prior to 5th Jan 2026

Premium v3 (P0v3): works consistently (single worker; no zone redundancy)

This is not a concurrency/limit scenario: we can reproduce with a single request / single get_data call.

Azure networking FYI (not claiming allowlisting)

We collected the outbound egress IP sets reported by Azure for the same Web App under respective Basic/Premium service plans and gathered the outbound IP addresses differs significantly (They are running the same code otherwise)

We understand this does not prove the root cause. However, it suggests the “Session is not opened” error may be masking an underlying network-level/session-establishment failure
(e.g., WebSocket/TLS handshake, routing, proxy interaction, transient disconnects) that manifests differently depending on the egress path of our deployment.

Questions

How can we obtain more detailed diagnostics from lseg-data / RTO when this occurs?

Is there a recommended way to enable debug logging and/or session callbacks so we can see the underlying reason the session is closed/not opened (e.g. handshake/auth/transport error codes)?

Are there any known network stability / proxy / WebSocket / TLS requirements (or known incompatibilities) for RTO connections from cloud PaaS environments like Azure App Service that could lead to this symptom?

Have there been any service-side changes since early Jan 2026 (protocol/endpoints/cert/TLS policy) that could make certain egress paths or environments fail session establishment?

We haven’t intentionally changed our application code or container image between the working period and now.

We also can’t fully rule out Azure platform changes, but the tier-dependent behavior makes us want to confirm if there are any RTO connection expectations or recent changes we should account for.

Thanks in advance

Jirapongse

@HenryI

Thank you for reaching out to us.

You can enable the debug log in the library by using a configuration file or coding.

Configuration file (lseg-data.config.json)

{      
    "logs": {
        "level": "debug",
        "transports": {
            "console": {
                "enabled": false
            },
            "file": {
                "enabled": true,
                "name": "lseg-data-lib.log"
            }
        }
    },

Coding: Run the code before calling the ld.open_session()

config = ld.get_config()

config.set_param("logs.transports.file.enabled", True)

config.set_param("logs.transports.file.name", "lseg-data-lib.log")

config.set_param("logs.level", "debug")


ld.open_session()

Then, the lseg-data-lib.log file will be created.

Please remove any private information from the log file before sharing it. Once we have the cleaned log file, we can check what the problem is.