1. Add surrounding messages to the given messages so we have a full screen of content to make it feel lively even in quiet rooms
- As you scroll around the timeline across different days, the date changes in the URL, calendar, etc
2. Add summary item to the bottom of the timeline that explains if we couldn't find any messages in the specific day requested
- Also allows you to the jump to the next activity in the room. Adds `/:roomId/jump?ts=xxx&dir=[f|b]` to facilitate this.
- Part of https://github.com/matrix-org/matrix-public-archive/issues/46
3. Add developer options modal which is linked from the bottom of the right-panel
- Adds an option so you can debug the `IntersectionObserver` and how it's selecting the active day from the top-edge of the scroll viewport.
- In the future, this will also include a nice little visualization of the backend timing traces
Follow-up to https://github.com/matrix-org/matrix-public-archive/pull/51
Better `child_process` error handling for a couple scenarios with the finger pointing at it 👉
Also make sure we handle all of these scenarios:
1. Child process fork script throws an `uncaughtException` or `unhandledRejection`
- These are captured and serialized back to the parent and stored in `childErrors` and exposed if we never get a successful rendered HTML response.
2. Child process fails to startup
- Render process is rejected in the `child.on('error', ...` callback
3. 👉 Child process times out and is aborted
- Render process is rejected in the `child.on('error', ...` callback and any `childErrors` encountered are logged
4. 👉 Child process fork script throws an error in scope of in `process.on('message', async (renderOptions) => {`
- Child exits with code 1 and we reject the render process with the error
5. Child process exits with code 1 (error)
- Render process is rejected with any `childError` info
6. Child process exits with code 0 (success) but never sends back any HTML
- We have a `returnedData` data check and any child errors encountered are logged
Split off from https://github.com/matrix-org/matrix-public-archive/pull/43
Listen to `process.on('uncaughtException', ...)` and handle the async errors ourselves so it no longer fails the child process.
And if the process does exit with status code 1 (error), we have those underlying errors serialized and shown.
OpenTelemetry tracing so we can see spans where the app is taking time.
For the user, we specifically show the spans for the external API HTTP requests
that are slow (so we know when the Matrix API is being slow).
Enable tracing:
- `npm run start -- --tracing`
- `npm run start-dev -- --tracing`
What does this PR change:
- Adds OpenTelemetry tracing with some of the automatic instrumentation (includes HTTP and express)
- We ignore traces for serving static assets (just noise)
- Adds `X-Trace-Id` to the response headers
- Adds `window.tracingSpansForRequest` which includes the external HTTP API requests made during the request
- Adds a fancy 504 timeout page that includes trace details and lists the slow HTTP requests
- Adds `jaegerTracesEndpoint` configuration to export tracing spans to Jaeger
- Related to, https://github.com/matrix-org/matrix-public-archive/issues/26
`renderHydrogenToString` is a pure function (probably) which means it will give the same output given the same input. This means, that if we give it a certain input and an error occurs, we should be able to reproduce it again if we have the arguments. This PR exposes those arguments in the logged error so we can investigate what's going wrong.
Added so we can investigate https://github.com/matrix-org/matrix-public-archive/issues/34 better and reproduce locally.
Remove `matrix-bot-sdk` usage in tests because it didn't have timestamp massaging `?ts` and it's not really necessary to rely on since we can just call the API directly 🤷. `matrix-bot-sdk` is also very annoying having to build rust crypto packages.
We're now using direct `fetch` requests against the Matrix API and lightweight `client` object.
All 3 current tests pass ✅
Eric Eastwood