Question
Diagnostic Console visibility boundaries for granular rollback error diagnostics in Fusion deployments
Rin Vale
0 reputation · 13 Jan 2020, 01:44 UTC
91.6K views
Loading…
0 reputation · 13 Jan 2020, 01:44 UTC
In current Oracle Fusion Cloud Applications releases, deployment failures can surface as generic Service Unavailable or Timeout responses in the UI while the Diagnostic Console reports only high-level service health without exposing underlying stack traces or specific database errors that triggered the rollback. Administrators relying on periodic log exports through the support interface face the risk that automated retention purging deletes relevant WebLogic managed server entries before manual investigation begins.
The unresolved behavior concerns whether rollback error granularity is fixed by design, governed by a configurable diagnostic setting, or restricted by a permission boundary separating UI-visible health status from backend log detail. Security policies that mask PII and system metadata further complicate data-dependent failure diagnosis, leaving uncertainty about what error detail is intentionally withheld versus available through a specific configuration path. Because documented behavior can vary across Fusion Cloud update cycles, the exact boundary between visible health status and accessible log detail may require confirmation against current release documentation.
Which configuration or permission boundary controls the visibility of granular stack traces and unmasked database error codes during a failed deployment rollback in Fusion Cloud? Does the Diagnostic Console expose a documented setting to increase error-code granularity beyond high-level service health, or is deeper log access strictly limited to periodic exports? How do automated retention windows interact with the time required to request and receive those exports when diagnosing a masked rollback failure?
35775 reputation · 13 Jan 2020, 07:56 UTC
In Oracle Fusion Cloud (SaaS), the level of detail you can see when a deployment rollback fails is not controlled by a user‑configurable Diagnostic Console setting. The boundary is set by Oracle’s managed‑service diagnostic policy and the permission model that separates the UI‑visible health status from the internal WebLogic and database logs. Only Oracle Support, through a formal Service Request (SR), can request the collection and preservation of those logs.
No documented customer‑visible configuration in the Diagnostic Console (or any other Fusion UI) allows a user to increase the granularity of error codes or reveal unmasked SQL messages. The only “settings” that affect what a user sees are role‑based permissions: a tenant admin can view health dashboards, but that permission does not grant access to the underlying logs.
Oracle’s SaaS environment automatically deletes old WebLogic log entries after a configurable retention period (often 30 days for some pods, 90 days for others). If you wait until a periodic export (e.g., monthly or quarterly) to request logs, the relevant entries may already have been purged. Therefore, the SR should be opened immediately after the error appears, and the request for preservation should be part of the SR creation. This mitigates the risk that the automated purge removes the data before you can retrieve it.
In the SR, request the name of the diagnostic setting (if any) that governs rollback detail for your specific release. If the setting does not exist, ask for confirmation that the behavior is fixed by design and that deeper logs are only support‑mediated.
To tailor the SR precisely, confirm the ECID or exact error message ID that appeared in the UI. Without that, Oracle cannot pinpoint the logs to preserve.
Oracle Fusion Cloud’s Diagnostic Console is intentionally limited to high‑level health status. Granular rollback diagnostics require a support‑mediated log collection, and automated retention can delete relevant entries before a manual export unless preservation is requested immediately.
Use comments to ask for clarification. Post a solution as an answer.
35,775 reputation · 13 Jan 2020, 09:58 UTC
To build on the point regarding Oracle Support requests, it is critical to emphasize the role of the Execution Context ID (ECID). Because Fusion is a multi-tenant environment with high log volume, providing a generic timestamp is often insufficient for rapid retrieval before automated purging occurs.
When a rollback failure occurs, administrators should immediately attempt to capture the ECID from the HTTP response headers or the UI error detail if available. This unique identifier allows support engineers to filter WebLogic logs across distributed managed servers, bypassing the need to manually parse massive log exports.
Since log retention is managed by Oracle and not configurable by the tenant, the gap between the failure and the SR creation is the primary risk factor. If the ECID is captured and provided in the initial SR, the likelihood of recovering the specific stack trace before the retention window closes increases significantly, as it enables targeted preservation of the relevant log segments.
fusion