testing-library/react-testing-library

Ok so some progress but its still not working as expected.

I i start caddy and go to my url I see the following on the `/__cache/souin` endpoint:

```
[
"GET-random-cma6sj5i.localhost-/api/shop/get/first-product",
"STALE_GET-random-cma6sj5i.localhost-/api/shop/get/first-product",
]
```

Now I do a purge request like above:

```
curl --location --request PURGE 'http://localhost/__cache/souin' \
--header 'Surrogate-Key: product-a58bb599-d96e-4d62-963d-20b3ce45092c' \
--header 'Host: localhost'
```

and I can see that indeed now the one item has been removed from the list:

```
[
"STALE_GET-random-cma6sj5i.localhost-/api/shop/get/first-product",
]
```

However now if I visit the page again it never gets readded and only lists the STALE_GET. The request itself comes back with:

```
Access-Control-Allow-Origin: *
Age: 167
Cache-Control: max-age=3600, public
Cache-Status: Souin; hit; ttl=3433; fwd=stale
```

How do I purge all entries completely with the associated surrogate key? its still serving the stale entry I think? I need to be able to just clear the entry completely once I give it a `PURGE` request with whatever key? 

Im trying to configure the cache through the json api with the following config:

```php

 "apps"  => [
                "cache" => [
                    'api'       => [
                        'basepath' => '/cache/',
                    ],
                    "log_level" => "info",
                    'ttl'       => '3600s',
                ],
]

```

I can see the cache working in the response (ive set a custom max age in my response going out)

```
Age: 8
Cache-Control: max-age=200, public
Cache-Status: Souin; hit; ttl=192
```

I can also see that the following request no longer hits my upstream and only caddy.

However when I go to my caddy instance: `caddy:2019/config/cache/` (is this right?) I only get `null` as a response not a list of cached keys? The purge method doesnt work either as it just returns `method not allowed` 

Im assuming im accessing the wrong api endpoint? Is the api endpoint configured over the caddy admin api or do I need to set up seperate routes in the caddy config to actually handle it?

API Config - Surrogate-key prune

caddyserver/cache-handler

ah thanks, have just tested it with badger on that commit and behaviour is still the same im afraid where it still clears the full cache instead of individual keys.

I'll try it on the olric side once I can figure out how to reload the config on it! Thanks for your help

@darkweak just had a look to try and purge the surrogate-key using badger (theres another issue with olric which ive created a new issue for) using the @latest tag and its still not working for me.

Can you confirm if I am sending the correct request structure?

```
curl --location --request PURGE 'http://localhost/__cache/souin' \
--header 'Surrogate-Key: product-a58bb599-d96e-4d62-963d-20b3ce45092c' \
--header 'Host: localhost'
```

It still just clears the full cache instead of an individual / multiple entries that have the associated surrogate key. But maybe this is also a badger bug

Caddy crashes when posting a new config to `:2019/load` when olric is enabled as the cache driver
Seems to not shut down the olric port gracefully / cant reuse it on reboot

```
caddy_1  | 2022/05/26 14:11:12 [INFO] Storage engine has been loaded: kvstore => service.go:129
caddy_1  | 2022/05/26 14:11:12 [DEBUG] memberlist: Got bind error: Failed to start TCP listener on "172.19.0.2" port 3322: listen tcp 172.19.0.2:3322: bind: address already in use
caddy_1  | Impossible to start the embedded Olric instance: Could not set up network transport: failed to obtain an address: Failed to start TCP listener on "172.19.0.2" port 3322: listen tcp 172.19.0.2:3322: bind: address already in use
caddy_1  | Closed EmbeddedOlricProvider chan
```

Also sometimes seeing this but not sure if related or not

```
caddy_1  | 2022/05/26 14:01:12 [INFO] Routing table has been pushed by 172.19.0.2:3320 => operations.go:87
caddy_1  | {"level":"debug","ts":1653573697.4362159,"logger":"http.stdlib","msg":"http: panic serving 172.19.0.1:40298: runtime error: invalid memory address or nil pointer dereference\ngoroutine 16465 [running]:\nnet/http.(*conn).serve.func1()\n\tnet/http/server.go:1825 +0xbf\npanic({0x1969700, 0x2c547a0})\n\truntime/panic.go:844 +0x258\ngithub.com/darkweak/souin/cache/providers.(*EmbeddedOlric).ListKeys(0x0)\n\tgithub.com/darkweak/souin@v1.6.8/cache/providers/embeddedOlricProvider.go:109 +0x1f2\ngithub.com/darkweak/souin/api.(*SouinAPI).GetAll(...)\n\tgithub.com/darkweak/souin@v1.6.8/api/souin.go:60\ngithub.com/darkweak/souin/api.(*SouinAPI).HandleRequest(0xc006e0f630, {0x7fc0373ab558, 0xc0008ec2a0}, 0xc000246400)\n\tgithub.com/darkweak/souin@v1.6.8/api/souin.go:90 +0x1b8\ngithub.com/darkweak/souin/plugins/caddy.(*SouinCaddyPlugin).ServeHTTP(0xc0000fa600, {0x7fc0373ab558?, 0xc0008ec2a0}, 0xc000246300, {0x1f50760, 0xc0008c1f60})\n\tgithub.com/darkweak/souin/plugins/caddy@v0.0.0-20220526084703-8bc41371ab53/httpcache.go:77 +0x94e\ngithub.com/caddyserver/caddy/v2/modules/caddyhttp.(*metricsInstrumentedHandler).ServeHTTP(0xc006e4c1c0, {0x1f5adf8?, 0xc0008ee000}, 0xc000246300, {0x1f50760, 0xc0008c1f60})\n\tgithub.com/caddyserver/caddy/v2@v2.5.1/modules/caddyhttp/metrics.go:132 +0x53b\ngithub.com/caddyserver/caddy/v2/modules/caddyhttp.wrapMiddleware.func1.1({0x1f5adf8?, 0xc0008ee000?}, 0x1f50760?)\n\tgithub.com/caddyserver/caddy/v2@v2.5.1/modules/caddyhttp/routes.go:272 +0x3b\ngithub.com/caddyserver/caddy/v2/modules/caddyhttp.HandlerFunc.ServeHTTP(0x1f50760?, {0x1f5adf8?, 0xc0008ee000?}, 0x7785c6?)\n\tgithub.com/caddyserver/caddy/v2@v2.5.1/modules/caddyhttp/caddyhttp.go:57 +0x2f\ngithub.com/caddyserver/caddy/v2/modules/caddyhttp.wrapRoute.func1.1({0x1f5adf8, 0xc0008ee000}, 0xc000246300)\n\tgithub.com/caddyserver/caddy/v2@v2.5.1/modules/caddyhttp/routes.go:244 +0x322\ngithub.com/caddyserver/caddy/v2/modules/caddyhttp.HandlerFunc.ServeHTTP(0x400?, {0x1f5adf8?, 0xc0008ee000?}, 0x1b06960?)\n\tgithub.com/caddyserver/caddy/v2@v2.5.1/modules/caddyhttp/caddyhttp.go:57 +0x2f\ngithub.com/caddyserver/caddy/v2/modules/caddyhttp.(*Server).enforcementHandler(0x0?, {0x1f5adf8?, 0xc0008ee000?}, 0xc0005fdcd0?, {0x1f50760?, 0xc006e4c200?})\n\tgithub.com/caddyserver/caddy/v2@v2.5.1/modules/caddyhttp/server.go:318 +0x252\ngithub.com/caddyserver/caddy/v2/modules/caddyhttp.(*Server).wrapPrimaryRoute.func1({0x1f5adf8?, 0xc0008ee000?}, 0x49ba97?)\n\tgithub.com/caddyserver/caddy/v2@v2.5.1/modules/caddyhttp/server.go:294 +0x3b\ngithub.com/caddyserver/caddy/v2/modules/caddyhttp.HandlerFunc.ServeHTTP(0xc0002eadc0?, {0x1f5adf8?, 0xc0008ee000?}, 0xc000246300?)\n\tgithub.com/caddyserver/caddy/v2@v2.5.1/modules/caddyhttp/caddyhttp.go:57 +0x2f\ngithub.com/caddyserver/caddy/v2/modules/caddyhttp.(*Server).ServeHTTP(0xc00027ea20, {0x1f5adf8, 0xc0008ee000}, 0xc000246300)\n\tgithub.com/caddyserver/caddy/v2@v2.5.1/modules/caddyhttp/server.go:230 +0xac6\nnet/http.serverHandler.ServeHTTP({0xc0008a7f50?}, {0x1f5adf8, 0xc0008ee000}, 0xc000246100)\n\tnet/http/server.go:2916 +0x43b\nnet/http.(*conn).serve(0xc0008dc000, {0x1f5c808, 0xc006bf2bd0})\n\tnet/http/server.go:1966 +0x5d7\ncreated by net/http.(*Server).Serve\n\tnet/http/server.go:3071 +0x4db"}
```

#### Reproducible example here:
https://github.com/mattvb91/caddy-cache-olric-bug

Cant update caddy config when olric enabled

mattvb91/caddy-cache-olric-bug

> We were experiencing this on GitHub Actions. Switching from Electron to Chrome resolved the hangs for us. Thanks @stuart-clark!

Thanks @bporcelli this fixed the issue for me. 

### Current behavior:

I feel like this kind of issue has been referenced many times before, but even after trying all the solutions I've found, we still continue to run into this problem. We've been seeing this issue for many months now, with early versions of Cypress 4.x and even with the most recent version today.

Long-running (multi-hour) test suites often "stall": the output stops appearing, but nothing actually fails or crashes. We actually have to rely on the timeout mechanism in Jenkins to kill the task because Cypress is just stuck.

I have enabled debug logs and honestly I don't see anything helpful in them. I'll upload the relevant portion next, but there are no mentions of failures, crashes, or even being out of memory. We're already following all the guidance in the Cypress docs about disabling /dev/shm and using the correct IPC setting.

### Desired behavior:

Tests should either run to completion or Cypress should fail with a clear error.

### Versions

Cypress: 4.12.1
OS: Linux
Browser: Chrome 83 (headless)

CI: jenkins

Prioritized to be picked up in current sprint

stage: backlog

Cypress sometimes stalls/hangs with no output when running in Jenkins with Docker

cypress-io/cypress

ah my bad yes I was instantiating a new olric container in my `docker-compose.yml` I didnt realize it was already included in the caddy image! Thats looking way better now.

For anyone else that stumbles on here from google / issue search my current config now looks like this:

```php
                "cache" => [
                    'api'         => [
                        'basepath' => '/__cache',
                        'souin'    => [
                            'basepath' => '/souin',
                            'enable'   => true,
                        ],
                    ],
                    'distributed' => true,
//                    'olric'       => [
//                        'url' => 'olric:3320',
//                    ],
                    "log_level"   => "info",
                    'ttl'         => '3600s',
                ],
```

and I can see the `/__cache/souin` list working. Also on initial glance I can do `PURGE` requests against for example `http://localhost/__cache/souin/GET-test-1-yargvp50.localhost-/api/shop/get/first-product` and I can see it getting removed from the list so its definitely working smoother! 

I will play around with the surrogate-keys later again from the other issue to report back on it!

When adding multiple hostnames to an upstream (?) after a certain amount of time (or certain number of hostnames) there is some kind of cache pollution happening.

Once the cache has been flushed the files return to giving good responses for a certain amount of time before the same happens again.

This has been reproduced in this sample repository here with minimal config: https://github.com/mattvb91/caddy-cache-bug

Samples taken from discussions over from  https://github.com/caddyserver/cache-handler/issues/26#issuecomment-1129657905

![image](https://user-images.githubusercontent.com/11991564/169806541-977a2619-d280-49f2-a166-92deaa0c15ae.png)

After cache flush:

![image](https://user-images.githubusercontent.com/11991564/169806557-5b145470-cc9b-4744-bdff-0b678c6c609f.png)

Here is a video of it happening in action:


https://user-images.githubusercontent.com/11991564/168979843-7b486e28-f4cf-4562-8ab8-ea64caa8d236.mp4


wait

Suspected cache pollution when adding multiple hosts

Just had a quick look with the `@latest` build and there is still some issue happening although not sure if related or new again.

The timings seem incredibly slow compared to badger: 

Olric: 
![image](https://user-images.githubusercontent.com/11991564/170466468-af140b35-0a37-4926-96be-9b59f3c300ce.png)

Badger:
![image](https://user-images.githubusercontent.com/11991564/170466614-b367fc61-46cc-4836-92fa-eb47b33a4ad1.png)

That nearly looks like olric cache isnt even working? Might explain why my `/__cache/souin` list is empty?

When I switch back to badger the `/__cache/souin` list works fine. So I think theres an issue with `olric` caching too.

My main config at the moment:


```php
                "cache" => [
                    'api'         => [
                        'basepath' => '/__cache',
                        'souin'    => [
                            'basepath' => '/souin',
                            'enable'   => true,
                        ],
                    ],
                    'distributed' => true,
                    'olric'       => [
                        'url' => 'olric:3320',
                    ],
                    "log_level"   => "info",
                    'ttl'         => '3600s',
                ],
```