Skip to Main Content
Optimizely Data Platform
Workspace Integrations
Created by Guest
Created on Feb 17, 2025

Separate Toggle for Developer exception page for ServiceApi requests

When working with exceptions from ServiceApi, 500 exceptions in the DXP environments result in a "Something went wrong" html page that does not provide any detail to the underlying error.

<!DOCTYPE html>
<html lang="en">

<head>
    <title>Something Went Wrong</title>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <link type="image/x-icon" rel="shortcut icon" href="/Util/images/favicon.ico" />
    <link type="text/css" rel="stylesheet" href="/Util/styles/errorpage.css" />
</head>

<body class="epi-workspace">
    <div class="error-wrapper">
        <div class="friendly-error">
            <h1 class="fiendly-error-header">Something Went Wrong</h1>
            <p class="fiendly-error-content">Something went wrong when trying to access this resource.</p>
        </div>
    </div>
</body>

</html>

The same error when running in the local developer environment will reveal the underlying error, for example:

System.ComponentModel.DataAnnotations.ValidationException: The page name must contain at least one visible character.
   at EPiServer.Core.ContentProvider.ThrowValidationException(ICollection`1 errors)

While I understand why a user of the website might not want to see such an error, the html error page response in the ServiceApi is quite useless and makes it impossible to handle the response appropriately.

I would propose either a custom toggle setting that would allow turning on/off the developer exception page, or just simply not use the same error page for ServiceApi 500 error responses as the website.

What's most important is getting the underlying error (the ValidationException above for example) rather than the "Something went wrong" html error page.

  • Attach files
  • Guest
    Reply
    |
    Feb 17, 2025

    It should be noted that it is possible to see the underlying error in the local development environment because of the app.UseDeveloperExceptionPage(); call in application Startup