Sprint 5 - Mischief Happens

This week I did some more incremental work on Hurl, finalizing the redirects query. On Startchart, I messed up a couple of things, fixed a couple of things and learned a couple of lessons!

Hurl

Add query for HTTP redirects (Link)

Last week, I enabled the code to pass down necessary information about HTTP redirections to queries. Continuing on that, I've been working on the redirects query itself.

Going back to the expected behavior proposed by the maintainer:

GET http://foo.com
HTTP 200
[Asserts]
redirects count == 2
redirects nth 0 url == "http://bar.com"
redirects nth 0 status == 302
redirects nth 1 url == "http://baz.com"
redirects nth 1 status == 302
url == "http://baz.com"

The query is treated like a list, you can perform assertions on the list itself, or get the individual HTTP redirect by index, and then assert on that.

Looking at the code one more time, they already had a Value::List(Vec<Value>) variant, and queries like count and nth were already implemented, so all I had left to do was to create another Value variant for HTTP redirection.

// `runner::HttpResponse`
// Name suggested by the maintainer 
pub struct HttpResponse {
    url: http::Url,
    status: u32,
}

and then

pub enum Value {
    ...
    HttpResponse(runner::HttpResponse),
    ...
}

And then came my favorite part about working in Rust, which was when the compiler told me everywhere else that needs to be changed.

For the evaluation method itself, a.k.a. the place where everything came together, I processed the passed-down responses into runner::HttpResponse. I popped the final response which was not considered a redirect. And finally, I constructed them into a Value::List. Here's the result:

fn eval_redirects(responses: &[&http::Response]) -> QueryResult {
    let mut values: Vec<Value> = responses
        .iter()
        .map(|r| Value::HttpResponse(HttpResponse::new(r.url.clone(), r.status)))
        .collect();
    values.pop();
    Ok(Some(Value::List(values)))
}

Startchart

Some package-lock.json Shenanigans

Never merge anything without testing first.

Last week, I merged a PR from my co-maintainer Uday. I didn't think it needed more testing since I had already reviewed it before, and there was only a rebase since then. Plus, the CI pipelines were all green.

Only after that did I realize, although the production build worked just fine, I couldn't run the dev build anymore. There were errors about missing dependencies:

...
node:internal/modules/cjs/loader:1244
  const err = new Error(message);
              ^

Error: Cannot find module 'colorspace'
...

I made a new clone of the project and set up everything from scratch. Still the same result. I messaged Uday to confirmed it. And or course, it worked on his machine 😆. We decided to revert the PR and investigate.

We spent the next couple of hours trying to reproduce and fix this, and eventially we narrowed it down to package-lock.json: We were only able to properly run the dev build if we used npm -ci instead of npm -i.

Then Uday had the idea to simply delete the lock file and re-generate it. We tried it and it worked! This time, of course, I learned the lesson and carefully tested everything.

Update on React hydration errors

Ever since this issue was created, I'd never been able to recreate it. I tried different browsers, different builds - nothing.

This came as a happy accident. I once left the site open overnight, and when I came back, all the stylesheets were gone! I immediately opened up the console. The first thing I noticed: There wasn't any warning of CSP this time.

Comment for #845

theoforger commented on Mar 21, 2025

I finally ran into this issue after leaving the "DNS records" page open and idle overnight. And other pages seemed to load just fine. It might not be related to CSP after all, since I didn't see the error message here.

Strangely, every time I refresh, the style sheet seems to load for a split second and then unloads itself:

https://github.com/user-attachments/assets/0299d9f7-9fe4-43fc-aa18-38320533542f

View on GitHub

I couldn't quite figure out what happened but I decided to look into the behavior even more. Here's what I found:

• The stylesheet was only broken on this particular page a.k.a. /dns-records
• Every time I refresh, the stylesheet loads for a split second and then unloads itself. (Maybe something to do with cache?)
• I could navigate to other pages and then back. In this case everything would load normally, but as soon as I refresh, the stylesheet was gone again.

Fix certificate content (Link)

I found this issue a while ago when I was looking into some certificate related issue. In short, the certificate files from the download links didn't have the correct information inside.

I looked into this expecting it to be some edge-case bug. But it really didn't take me long to find the problem inside the download handler:

...
case 'certificate':
        return createResponse(certificate.certificate, `${certificate.domain}.certificate.pem`);
      case 'privateKey':
        return createResponse(certificate.privateKey, `${certificate.domain}.privkey.pem`);
      case 'chain':
        return createResponse(certificate.certificate, `${certificate.domain}.chain.pem`);
      case 'fullChain':
        return createResponse(certificate.certificate, `${certificate.domain}.bundle.pem`);
...

This turned out to be a much simpler fix than I anticipated - The handler was grabbing the wrong content: In case of chain and fullChain, it was serving the end-entity certificate instead.