| 13 Oct 2025 |
 raitobezarius | that's kinda a semi bug and a semi accepted thing | 19:39:51 |
| raitobezarius | why would that lead to destroyed UX? | 19:39:59 |
 Yureka (she/her) | Because when there is still an entry in the narinfo cache, Lix will explode upon trying to fetch the Nar | 19:40:08 |
 hexa | yeah, that is bad ux | 19:40:16 |
| raitobezarius | That's Bad™ | 19:40:17 |
| raitobezarius | narinfo cache should be cache | 19:40:27 |
| hexa | with gcing caches you should set a shorter negative lifetime for the cache | 19:40:37 |
| raitobezarius | cc ma27 — I remember you did stuff on the narinfo cache or am I misremembering? | 19:40:41 |
| Yureka (she/her) | How? | 19:40:47 |
| hexa | narinfo-cache-positive-ttl = 3600;
| 19:40:59 |
| Yureka (she/her) | on the client? | 19:41:13 |
| hexa | yeah | 19:41:16 |
| hexa | Redacted or Malformed Event | 19:41:20 |
| hexa | * with gcing caches you should set a shorter positive lifetime for the cache | 19:41:44 |
| Yureka (she/her) | yes yes I know the option, but I don't like that there is no way to fix this from the server (like remotely advertising a ttl) | 19:41:58 |
| raitobezarius | either way, lix shouldn't crash on actually 404s NARs | 19:42:18 |
| Yureka (she/her) | but even with a low TTL, it's not "safe" to gc | 19:42:22 |
| hexa | yep | 19:42:30 |
| raitobezarius | it should gracefully consider that nar nonexistent | 19:42:31 |
| raitobezarius | then you can also evict it from the narinfo cache as well | 19:42:42 |
| raitobezarius | this should be at most inefficient | 19:42:49 |
| Yureka (she/her) | I thought I fucked up the integrity of my cache, so I entirely recreated the cache and re-populated it with contents from the old cache, but it kept crashing | 19:42:58 |
| Yureka (she/her) | so now I know this is just normal(TM) | 19:43:17 |
| Yureka (she/her) | after some hours of debugging | 19:43:19 |
| raitobezarius | i think we don't need to keep up the act and we can say it out loud | 19:43:21 |
| raitobezarius | any cache | 19:43:22 |
| raitobezarius | in | 19:43:23 |
| raitobezarius | this codebase | 19:43:26 |
| raitobezarius | should be considered your enemy | 19:43:30 |
| raitobezarius | (this is almost not even a joke, i cannot count how many unsound caches we have in the codebase, some known, some we stumble on like "wait what?") | 19:43:54 |
