After a short break, it's time to get back to the second half of this sprint. This time, I worked on a new feature and some maintenance for Starchart, as well as more followup work for Hurl.
🌐🦀 Hurl
Integration Tests and Docs (Link)
As a followup of the previous PRs, this one finally concludes the ip query feature! As I'm getting more familiar with this project, I now know exactly where to look when it comes to docs and integration tests.
However, some tests are still failing due to "patternization": The integration test system checks the output and compares it with an expected value. However, some output information is run time specific. For example, performance metrics and timing information is different for each run. So the output for these data should be patternized:
| Original | Patternized |
|---|---|
"timings":{
"app_connect":0,
"begin_call":"2025-03-05T22:38:53.547654Z",
"connect":207,
"end_call":"2025-03-05T22:38:53.563185Z",
"name_lookup":34,
"pre_transfer":248,
"start_transfer":15444,
"total":15468
}
|
"timings":{
"app_connect":"<<<\\d+>>>",
"begin_call":"<<<.*?>>>",
"connect":"<<<\\d+>>>",
"end_call":"<<<.*?>>>",
"name_lookup":"<<<\\d+>>>",
"pre_transfer":"<<<\\d+>>>",
"start_transfer":"<<<\\d+>>>",
"total":"<<<\\d+>>>"
}
|
However, according to the maintainer, there doesn't seem to be a way to automate this. So fixing it would be manual labor, which is not the end of the world since they don't have many tests like this.
Good News!
In a previous blog I shared my concern that the Hurl project might take a break from contributions. Ho I'm happy to inform that they made an exception for me!
Of course, I totally understand why they made that decision in the first place: There is huge influx of contributions, a planned release, and considering how much care and patience they put into each contribution, it's a lot of work! I'm flattered by this exception made by them, but at the same time, it's reassuring and inspiring to see my work being recognized.
⭐🗺️ Starchart
Update Dependencies (Link)
Of course, it can't be another week on Starchart without some good old dependency updates. This time I really tried to eliminate as many of them as I could:
I knew upgrading to React 19 was going to be painful, since it introduced a ton of breaking changes. However, as I always do with upgrades like this, I tried to upgrade it anyway and see if anything would break. To my surprise, when I tested it locally, other than one small issue regarding the JSX namespace, it just worked!
However, when I filed the PR, I was welcomed with a failed e2e test. Turned out some code is broken in mobile safari browser:
3 failed
[Mobile Safari] › test/e2e/certificate-available.spec.ts:66:7 › Certificate Page › Download Certificate
[Mobile Safari] › test/e2e/header/header.spec.ts:11:7 › sign out of the account › sign out ─────
[Mobile Safari] › test/e2e/landing-page.spec.ts:25:7 › Landing Page › DNS Records Instructions Link
1 flaky
[Mobile Chrome] › test/e2e/landing-page.spec.ts:25:7 › Landing Page › DNS Records Instructions Link
Truly an "it work on my machine" moment 😂.
In addition, I attempted to upgrade express to v5. I did notice that version 5 was marked with the "next" tag, but my inner "Arch Linux spirit" was telling me to update anyway! Turned out it wasn't the best decision I've made, as others prefer to stay at v4 for now.
MX Records (Link)
This was the major feature of this sprint! As we frustratingly navigated through various dependency updates and eventually realized that it's a never ending ride, I decided to finally start working on this feature request to support DNS MX records.
Like I said in the title, I had a complicated relationship with DNS. As someone who's battled with internet censorship for many years, DNS has always been the number one pain point no matter which proxy tool I choose. However, at the same time, I can't help but admire the simplicity of it and the critical rule it plays in modern internet infrastructure.
Even though I also had experience managing DNS records for my home server, I've never dealt with MX records before. Research time!
I came across this short article from Cloudflare which explained it well. Like many other common DNS records, there isn't much complexity to it.
| example.com | record type | priority | value | TTL |
|---|---|---|---|---|
| @ | MX | 10 | mailhost1.example.com | 45000 |
In this example, the record essentially says:
Any email destined for the root domain example.com should be delivered to the mail server at mailhost1.example.com. In case this record fails to resolve, look for other records with priority higher than 10. And this record will come into effect in 45000 seconds.
The implementation wasn't too hard either. I modified the prisma schema file to include the MX record type:
enum DnsRecordType {
A
AAAA
CNAME
MX
TXT
}
And made sure the value includes a priority as stated in the documentation (I decided to use 10 as the default since priority is irrelevant in this project):
if (type === DnsRecordType.MX) {
return '10 ' + value;
}
Now, the only problem is that, while the unit tests and integration tests can both past, since DNS is pratically a public service and in this case also involves a mail server, I couldn't figure out a way to test if it's actually functional. I already opened a draft PR. Let's hope we can find a solution together!
Top comments (0)