The person that found this is a hero.
Whenever I see slightly weird behaviour, there is a temptation to just move on because there isn't enough time, running software is complicated, and there is something else I want to do. I will try to change my attitude in future in case it uncovers a backdoor like this -- it would be educational too.
The manifest of my Kubernetes cluster is managed in a Git repository and is automatically deployed via a GitOps tool named Flux CD. When I push changes to the repository, such as adding a new application or upgrading Docker images, the deployment occurs within a few minutes.
This is the way.
Although I use Flux ImageUpdateAutomation instead of Renovate Bot. Did you consider using Flux to do auto updates? Are there any downsides that made you choose Renovate Bot instead?
I don't know if it is ideal for a research paper, but we have been using semgrep with Rust. Semgrep allows you to write your own linter rules to enforce code standards.
I have found some basic rules on the internet (e.g no unwrap()) but we have mostly had to write our own rules because there are only a few for Rust.
I think it would be a helpful project to write a Semgrep rule set that Rust developers could use. Maybe the "research" part would be looking at rulesets for other languages.
I don't think the survey was advertised? For me it popped up when I was writing something in the Rust Playground.
Despite using Tokio underneath, I think that Actix does NOT do work stealing and uses mostly separate threads:
Given this architecture, I think the article might inaccurate when it says that Actix handlers must be Send + Sync. See also: https://www.reddit.com/r/rust/comments/14cbe1u/why_does_actixwebs_handler_not_require_send/
Actix is a bit weird, but it has been around, and used in production, for a relatively long time.