This is the page where we document common errors/pitfalls and how to fix them:

Refer also to the known issues document.

Content Security Policy violations

If you’ve received an error like this:

Refused to load the image ‘https://example.com/thing.png' because it violates the following Content Security Policy directive: “img-src ‘self’”. This means you’re trying to add a link to a resource that is not allowed. Learn more about the decision to add this content security policy (CSP) in the decision document.

To fix this, adjust the CSP to allow the resource you’re trying to add. This can be done in the server/index.ts file.

Launch Darkly initialization failure

If you’ve received an error like this:

error: [LAUNCH_DARKLY] waitForInitialization timed out after 5 seconds.

error: waitForInitialization timed out after 5 seconds.

You might have network connectivity issues, as launch darkly requires internet connection.

SSO login in atomic dev / vite dev server

Problem: When we’re working in any of our dev environments (whether its Tilt, atomic env or against the vite dev server), we’re authenticating against the same Descope environment (dev). When we configured SSO for the dev environment, we had to choose a single ACS URL, which is the endpoint that the service provider (in our case, Okta) will redirect to after successful authentication. We configured it to be https://localhost, which is the URL of the frontend service when running Tilt locally.

This means that when we’re working against the vite dev server, we’re not able to authenticate with SSO out of the box, because the URL of the frontend service is http://localhost:3000, which is not the same as https://localhost. Same goes for the atomic dev environment.

Solution: Change the URL in the browser manually to the relevant URL of the frontend service, according to the environment you’re working in.

Also, feel free to refer to this document for more details on how SSO works in general and in our application.