Thibault Charbonnier

This is probably much too late and there may exist better solutions today, but it is done, thanks all.

Overall I cannot stress hard enough that mlcache users in an application as complex as Kong should **only** use `:get()`, which is an extremely, extremely powerful, clean, and performant interface...

> Can you help me understand your use case here? Any insight into why your build might have become closed before you send an (additional) job with another coverage report?...

Thanks for the update! I guess I don't really understand why this changed? In the past, we've been able to restart as many builds as we want and just get...

Well, I just tried it on a branch I have been working on and got the HTTP 422 again, so it seems to be the case that this changed recently...

Thank you both for the help and suggestions! My whole team is out until Tuesday but I will try it out, maybe sooner if I get a chance to.

Trying the above suggestion in the repo currently. @afinetooth Perhaps the only difference between the workflow you elaborated and ours, is that we force-push PRs quite often. Clean git history...

New error from the build on the PR where I added the above env variable: ``` Sending to coveralls { repo_token: '***', carryforward: 'unit-ngx_1.25.0-wasmer-ssl-debug-no_hup,unit-ngx_1.25.0-wasmer-ssl-no_debug-no_hup,unit-ngx_1.25.0-wasmtime-ssl-debug-hup,unit-ngx_1.25.0-v8-ssl-debug-no_hup,unit-openresty_1.21.4.1-wasmtime-ssl-debug-no_hup,unit-ngx_1.21.6-wasmer-ssl-debug-no_hup,unit-ngx_1.25.0-wasmer-no_ssl-no_debug-no_hup', repo_name: 'Kong/ngx_wasm_module', payload: { build_num: '5335826735',...

Yesterday I applied the `env` fix without bumping to `@v2` and got `Error: Parallel webhook error:Error: {"error":"No build matching CI build number 5341291030 found"}, {"error":"No build matching CI build number...

> Now, I will try and manually delete all the past builds of this PR branch and run our CI workflow again, at least to see if non-forced-pushed branches works...