| 08:33 | <Jake Archibald> | annevk: are you saying that Chrome's implementation is doing the right thing (Response.error() returned from the service worker results in a failed fetch), but some tests suggest it should do something different? |
| 08:44 | <annevk> | Jake Archibald: I think the main oddity I found is that you can store it in the Cache API |
| 08:44 | <annevk> | Jake Archibald: which both does and does not make sense, so I guess it's okay |
| 08:50 | <Jake Archibald> | annevk: hmm yeah, I see what you mean. I guess it's fine. The only way to get one of those errors is Response.error() right? |
| 09:00 | <annevk> | Jake Archibald: yes |
| 09:01 | <Jake Archibald> | yeah, it's fine I think. Having errors end up in the cache unintentionally might be an issue. |
| 09:01 | <Jake Archibald> | But it seems like it has to be pretty intentional now |
| 11:35 | <annevk> | Weird, I'm suddenly getting hgroup errors again for whatwg/url PRs |
| 11:36 | <annevk> | As far as I can tell bikeshed-boilerplate and bikeshed-data are both good. TabAtkins is api.csswg.org known to sometimes use an old version or some such? |
| 11:36 | <annevk> | sideshowbarker did something change in the validator perhaps? |
| 11:40 | <annevk> | Also weird, PR Preview still has an h2 in the hgroup. I guess it uses some other kind of template? |
| 11:49 | <annevk> | Hmm, seems to have been some kind of fluke? Builds are passing again. Very weird. |
| 11:57 | <sideshowbarker> | sideshowbarker did something change in the validator perhaps? |
| 11:59 | <annevk> | Yeah, looks like it was an api.csswg.org fluke of some sort. |
| 12:00 | <annevk> | Thanks! |
| 12:45 | <Domenic> | It might be because the PRs are not rebased on main |
| 12:51 | <annevk> | Domenic: that would not explain it failing first and later passing without changes to the PR |
| 12:52 | <annevk> | If you're curious you can look at the two commits of https://github.com/whatwg/url/pull/722. First one still has its failing result. The second also failed, but I ran CI again. |