Example threads. These questions and answers were written by the SDODS team to document real problems and how to fix them. The people named are illustrative, not real users. Questions asked on this site are marked new.
Running sdods serve behind our reverse proxy. The run detail page is fine, screenshots load, the API panels load, and then the trace link goes to:
GET /trace/?trace=/api/runs/018e1c44-.../files/runner-output/.../trace.zip
404Every other static path under the server works, so I assumed I had broken something in the proxy config, but I cannot find it and a colleague reproduces it with no proxy at all. Is /trace/* supposed to be served by the SDODS server?
Accepted answer
Not your proxy. /trace/* is served from the runner's bundled trace viewer, and under Bun's package layout that path may not resolve — when it does not, the route returns 404. It is a known limitation rather than a misconfiguration, and it is still open.
The workaround is local:
sdods trace --run 018e1c44-4c07-7a19-b6d2-11f0c3e94a55 --list
sdods trace --run 018e1c44-4c07-7a19-b6d2-11f0c3e94a55The artifact itself is fine — GET /api/runs/:id/files/* serves the zip perfectly well, it is only the viewer that is missing. So if the run is on a CI machine, download that one trace.zip and open it locally, or drop it on trace.playwright.dev.
It is the "Trace viewer" row in known limitations.
Confirming it is on our side. Do not spend any more time on the proxy — nothing you can put in front of the server makes that route exist.
Two things soften it in the meantime. The failure screenshot and the step narrative in the run viewer answer most of what people open a trace for, and for the rest sdods trace is one command against a downloaded run directory.
Wrap commands and output in triple backticks and they will render as a code block.
Checking whether you’re signed in…
Have a different question? Ask it.