Dave, I hate to interrupt, but I’ve detected a fault in one of my circuits.
I’ve stumbled on a need for this as well as a way to implement it: Software that re-runs its test suite on itself after updating its fixtures based on new environmental factors. The next step (which I’ll start working on) is software that fixes itself.
I realized that maybe people in the Elixir/Erlang community may have done work in this area, given the hot-swappable nature of the system. Anybody heard of work like this? It’s been surprisingly tricky to search for because I end up with lots of hits for automated testing, which is only a lower-level component of what I’m talking about.
EDIT: It looks like self-healing might be the thing I’m after.
Correct me if I’m interpreting this incorrectly, but isn’t what you’re describing like a CI pipeline that runs when certain conditions are met rather than on code commit?
I’m interested since I working on an app that tests test quality and this might be in the same wheelhouse.
I know some embedded engineers write code that checks memory content at runtime to ensure the code being executed is actually what is supposed to be executed. Something to do unstable hardware. And of course fixing that after detecting mismatch.
Actually, it’s a piece of an ETL pipeline that will run daily. And so I’d it to refuse to run if the input format has changed too much. It’s Haskell that I’m going to try implementing in Elixir: https://github.com/public-law/nevada-revised-statutes-parser
You should probably view this in context. Any “true” AI – like a sentient, intelligent being – that is much better and more durable than us, will likely have a stream of consciousness. Part of that includes continuously pulling diagnostic information and evaluating it; sort of like you will know if you suddenly got a leg cramp in the next milliseconds of it happening.
Truth is, having an artificially sentient entity will mean a lot of not-so-energy-efficient activities happening all the time; it cannot just react to things, it has to take the initiative and continuously process sensory information… sort of like us.
To create a software that fixes itself you’ll need a ton of specifications, goal-oriented programming, and you also must have a feedback mechanism (which answers the question “is the result of this function correct”?). I am not saying it’s impossible; it definitely is possible. And you’ll also probably need some logic programming as well (Prolog).
If you code for the “happy” path—and make your pattern matches really strict—you will see it in your error logs every time your application encounter something unexpected. You can then decide on what to do in these discovered cases.
Besides the stuff that is build in to OTP (i.e. Supervision), patterns such as safety-valves and fuses can help you detecting and handling errors in regards to third-party systems—this way you can detect if something is wrong in your circuits and act accordingly
Safe healing, I think it could if you meant to automatically get back in time instead of trying to invent a new patch to fix itself. Like, if a test fails or that some of the web pages display errors, you could code something using git bissect that would find the culprit and go back in time enough to work again, until YOU fix the problem and push the fixed version.
It’s only more complicated because nobody coded that yet. But indeed it would merge some aspects of CI into the server itself. That’s probably not a very good idea except for a fun project (for some definition of fun).
