Bug Report: full_search() hangs / fails in MicroStrategy Cloud but works in hosted/on-prem environment

[kkadu]

Description

mstrio.object_management.search.full_search() hangs and eventually fails in our MicroStrategy Cloud Environment (MCE), while the same code, same object types, and same lineage workflow continue to work in our hosted/on-prem environment.

This issue appears to affect only the Cloud environment and started recently without any code changes on our side. Until recently, full_search() was working in the Cloud environment as well.

Our lineage harvester uses full_search() during recursive object discovery. For example, starting from a document/dossier, it identifies downstream report/cube objects, and then recursively identifies components such as attributes and facts. This workflow now fails in Cloud because full_search() either hangs or times out and then returns a History List related error.

The behavior suggests a possible issue with one of the following in MicroStrategy Cloud:

1. Search index / Quick Search backend health
2. History List lookup for asynchronous search jobs
3. Cluster/load-balanced node behavior, where search submission and polling may be reaching different nodes

Observed error pattern includes a message similar to:

ERR004: Object does not exist in the history list

This makes us suspect that the search request is created successfully, but the follow-up polling request may not be able to locate the corresponding result/job.

MicroStrategy Support Case

No support case has been raised yet.

Our current working hypothesis is:

• full_search() relies on the MicroStrategy search backend and asynchronous job/result retrieval.
• In hosted/on-prem, requests are effectively handled by a single dedicated environment, so the search request and subsequent polling resolve correctly.
• In MicroStrategy Cloud, requests may be routed across multiple nodes behind a load balancer. If the initial search is processed on one node and the polling request lands on another node, the History List lookup may fail with ERR004.
• A secondary possibility is that the Cloud search index became stale, locked, or corrupted after a recent patch or infrastructure change.

We would like help confirming whether this is:

• a known issue in Cloud,
• a search indexing problem,
• a node affinity / load balancing issue,
• or an issue in how full_search() interacts with clustered cloud deployments.

Steps To Reproduce

1. Establish a valid mstrio connection to a MicroStrategy Cloud environment.
2. Execute full_search() for an object name that is known to exist.
3. Observe that the call hangs or takes a very long time.
4. Eventually, the request fails with a History List related error such as:
   • ERR004: Object does not exist in the history list
   • or a message suggesting rebuilding the History List
5. Run the exact same code against our hosted/on-prem MicroStrategy environment.
6. Observe that the search returns successfully and promptly.

Additional notes:

• This behavior is reproducible in Cloud and not reproducible in hosted/on-prem with the same workflow.
• Direct object-specific API calls continue to work in Cloud; the problem appears isolated to full_search() / search-related behavior.
• This issue started recently; previously the same Cloud environment supported this workflow.

Code Snippet

from mstrio.connection import Connection
from mstrio.object_management.search import full_search

# Placeholder values
BASE_URL = "https://<your-env>/MicroStrategyLibrary/api"
PROJECT_ID = "<project_id>"
IDENTITY_TOKEN = "<identity_token>"

conn = Connection(
    base_url=BASE_URL,
    identity_token=IDENTITY_TOKEN,
    project_id=PROJECT_ID
)

# Minimal reproduction
results = full_search(
    connection=conn,
    name="Sample Report",
    limit=10
)

print(results)

Additional Context (optional)

Relevant environment details:

• mstrio version: 11.5.10.101
• Execution environment: Databricks notebook
• Hosted/on-prem environment: works
• MicroStrategy Cloud environment: fails
• Same lineage code path works in hosted but hangs/fails in Cloud
• No known code change on our side between working and failing behavior

Evidence that may help narrow root cause:

• The issue appears isolated to full_search() and search-related operations.
• Direct endpoint-based calls for object retrieval continue to work in Cloud.
• The failure references the History List, which suggests the asynchronous search job result cannot be found during retrieval.
• The fact that hosted works but Cloud fails points to an environment/configuration/infrastructure difference rather than application logic.

Possible areas to investigate:

• Quick Search / search index health in Cloud
• History List synchronization across cluster nodes
• Load balancer stickiness / node affinity for search job submission and polling
• Recent Cloud patching or configuration changes affecting search