This morning I was looking at some log entries in GlitchTip and went to filter by log severity to see what was being recorded.
GlitchTip, by the way, is an open source error tracking tool. It's pretty fancy, I have a lightweight instance I run to capture debug output from a handful of projects I operate personally. Errors or log messages from applications can be relayed to GlitchTip for review, notification, and other similar features.
I was surprised to see that there wasn't any UI for how to filter down to eg "error" or "debug" level entries. I thought this was existing functionality but was (perhaps of course) thinking of other tools. I also noticed that the level of each message (or issue) was not represented textually, instead showing only as a colour bar to the side of the entry in the UI.
I opened the browser's inspector and copied the API requests out as a curl command, then tried some variations for filtering syntax - ?level=info, ?query=level:info - to see if the API supported it. It didn't appear to. There was no indication of support in the front end either, while I saw other UX hints from autocomplete on environment: etc.
This now had my interest, and I checked out the GlitchTip project Gitlab to see if I could find an issue where this was being requested or worked on. Searching for "severity", "level", "type" led me to glitchtip/glitchtip-frontend#161: Add UI for error levels to issue list page which at least confirmed for me that the colours I'd noticed earlier did relate to the levels of the entries.
I checked into GlitchTip's chat to ask if this was an existing feature request, and was fortunate to have a few pointers from one of GlitchTip's core contributors, David Burke, including an existing issue glitchtip/glitchtip-frontend#185: Feature Request: Filter "message events" out of the issues list, which the keywords I'd tried searching for hadn't surfaced.
Since I didn't know Django at all, I figured the best first step would be to write test coverage for the desired functionality. I made a first attempt at a test, and ran the tests with docker compose exec web ./manage.py test apps.issue_events. I expected my changes to have a heavy foreign accent, not being much familiar with Django or even Python. To my incredulity not only did the proposed code pass GlitchTip's lint checks, but the tests passed as well. I was pretty confident this meant my tests were flawed.
David kindly showed me I had implemented a test which tested the wrong thing - whether the issues were tagged with named levels, rather than whether the issues had levels assigned.
I already had the backend component running locally, and wanted to be able to poke at the API directly with these changes in place to test. Getting an API key however looked like it would require attaching the frontend service component. I had the feeling it might be a diversion but was told this was the easiest way to get an authentication token. Then I found that the frontend setup steps didn't work for me, exiting with a "bus error" each time I ran npm install.
This had me stuck for a little bit, so after talking with David some more about the error I saw, I went and tidied up the yard for a bit, trimmed some edges and mowed some grass. When I came back I had realised that it was unnecessary to set up a build environment at all ... I could download a fresh set of built files from the frontend project's build-assets CI job! So I grabbed those, copied them into the local backend development instance I had available, and was finally able to see the GlitchTip UI.
Now I needed to get a login to the instance. It had come up with an unknown admin email address. A bit of research led me to Django's createsuperuser command, which I used via ./manage.py:
$ docker compose exec web ./manage.py createsuperuser
Email: test@example.com
Password:
Password (again):
Bypass password validation and create user anyway? [y/N]: y
Superuser created successfully.Once this was done I could log into my local GlitchTip instance and configure it with the required data to get access to a token for testing the behaviour of the client.
I now rewrote the test so it now (correctly, I believe) failed. I then added a few lines to the Issue model to implement the filter, and once more, to my pleasant surprise, the test now passed. I tried a few additional test changes, confirming various changes or inputs could fail the test, to confirm things were working as intended, which it seems like it does. Wow. That was too easy?
The GlitchTip codebase has a rewrite under way to make event and issues APIs more efficient, and David had pointed me at that branch (with some special instructions on how to test it). The tests were passing both locally and in CI, locally with the rewrite changes active and in CI without. I was ready to push the changes for consideration and did so. The resulting MR is at glitchtip/glitchtip-backend!767.
I really enjoyed this first brush with the GlitchTip codebase. I was impressed by the project's clear guidelines in CONTRIBUTING.md, with a good section on code style and philosophy to align contributions. I especially liked -
Economical over completeness. Make running GlitchTip as easy and simple as possible, especially for small and medium sized projects. Be wary of introducing additional external dependencies. The entire project must be maintained on a budget of 4 person-hours per week. When introducing a large new feature, offer to help with maintenance in addition.
I also thought that guidance like what to avoid was a really helpful step, eg:
Avoid: Inefficient database calls - GlitchTip must work for both small self hosters and 100 million event projects. Always assume scale. If you need to edit every user, assume there are 100 million users and the queries much be chunked in batches. Neither one query per user nor one giant query that takes too long to execute.
(See the full CONTRIBUTING.md for other guidance - it's a sign of a healthy setup to me that this has been reflected on, and is at the fore.)
I enjoyed working with the project today and found the project layout and Django's experience really well formed. I'm be interested to learn more about this framework I've long heard of and not engaged until now 🐍 and excited to look forward to a second round of feedback on the MR.
A positive reflection was that when the missing functionality caught my eye, my initial response was one of interest - both that the feature wasn't there, and how it might be implemented. That attitude supported me to take the step to trying a commit in a system outside my usual toolkits, and I appreciate the experience and outcome. If that first mental/emotional had been disappointment, annoyance, frustration or even resignation ... I think I wouldn't have tried half of the steps I did, and that would have limited the outcomes. It's not all attitude, but it sure helps.
Update: A day later, glitchtip/glitchtip-backend!767 was accepted and will be available in the first release of GlitchTip 4.0! 🎉