credential delegation not found (404) / permission delegation name (500)

[ncastagnet_mc]

Hi,

We run a monitoring integration that reads a Genie space's conversations via the Conversation API, using a service principal with CAN MANAGE on the space - capturing each conversation's prompt, generated SQL, and query result.

Listing conversations and reading the prompt + SQL work fine. Fetching the query result fails:

GET /genie/spaces/{space}/conversations/{conv}/messages/{msg}/attachments/{att}/query-result

- Most: 404 NOT_FOUND - "Could not generate a reply because the required credential delegation was not found."
- Some: 500 DATA_LOSS - "Attempted to use embedded credentials but could not find permission delegation name."

The wording suggests the results were produced under a credential/permission delegation that the service principal can't resolve when fetching them later.

What we're trying to figure out is what to change so a monitoring service principal can read these results:
1. Is retrieval tied to how the space runs queries - end-user credentials vs a shared/"maker" service credential - and would switching to a shared credential make results retrievable by a service principal?
2. Is there a space/workspace setting (e.g. "Genie chat sharing" / "Reviewable by space managers") that makes results retrievable via the API for a non-owner service principal, or does it only affect UI visibility?
3. Is the 500 DATA_LOSS / "permission delegation name" a known issue or a fixable misconfiguration? Happy to share server-side request_ids if needed.

The goal is to advise the space owner on the exact change needed, or, if we need to change something in how we use the APIs, address that as well. Thanks!

Thanks in advance!

[Lu_Wang_ENB_DBX]

Summary:

1. Yes — result retrieval is tied to the query’s credential/delegation model. Your 404/500 messages point to missing or unresolved permission delegation for those stored results, not missing CAN MANAGE on the space. If you need a monitoring service principal to read results consistently, the safest pattern is to run the Genie/API workload under a shared service-principal identity rather than per-end-user delegated credentials.

2. Genie Chat Sharing matters. When enabled, and when a conversation is set to Reviewable by space managers, users with CAN MANAGE can review the full conversation/results; if the conversation is Private, managers can see prompts but not results. Existing conversations created before the feature was enabled stay Private; new ones default to Reviewable by space managers after enablement.

3. The 500 DATA_LOSS / “permission delegation name” looks like a backend issue or mis-propagated sharing/delegation state. The wording matches internal delegation plumbing, where the delegation name must be persisted and later assumed; if it is missing, retrieval can fail exactly this way.

Recommendation:

• Turn on Workspace Admin → Previews → Genie Chat Sharing.
• Ensure the conversations you want monitored are Reviewable by space managers (or All account users), not Private.
• For reliable machine monitoring, prefer a shared SP-run integration that creates/reads the conversations itself.
• For the failing 500/404 cases, open a support/engineering ticket with the request_ids — this likely needs server-side investigation of missing delegation metadata.

Most likely root cause in your case: those conversations/results were created without a retrievable delegation context for the monitoring SP. Enabling Chat Sharing helps manager visibility, but if the stored delegation metadata is missing, you’ll still need a backend fix for those affected conversations.

[ncastagnet_mc]

Thank you very much, @Lu_Wang_ENB_DBX   — this is really helpful and provides great insights! As a first step, we’ll ask the customer enable Genie chat sharing and check whether our monitoring identity can then read the results. If the 404s/500s persist, we’ll file a support ticket with the request IDs and more details. Thanks again!