This feature adds a "Run On Startup" feature for Actions. When enabled, the action will be executed shortly after Komodo Core finishes loading.
Now first, I am experienced in C, not Rust, so forgive me if I did anything stupid. I mostly just borrowed from how actions were run in schedule.rs for borrowing the syntax / patterns to do what I wanted to do.
Originally, I added the startup actions in startup.rs at the end of the on_startup function (like this)
My reasoning was that this needed to occur after the server becomes available here
ifconfig.ssl_enabled{info!("🔒 Core SSL Enabled");rustls::crypto::ring::default_provider().install_default().expect("failed to install default rustls CryptoProvider");info!("Komodo Core starting on https://{socket_addr}");letssl_config=RustlsConfig::from_pem_file(&config.ssl_cert_file,&config.ssl_key_file,).await.context("Invalid ssl cert / key")?;axum_server::bind_rustls(socket_addr,ssl_config).serve(app).await.context("failed to start https server")}else{info!("🔓 Core SSL Disabled");info!("Komodo Core starting on http://{socket_addr}");axum_server::bind(socket_addr).serve(app).await.context("failed to start http server")}}
However, I don't really know how to get it to run after this in the way I was hoping.
So I sort of hacked it by just spawning the process to run the actions in the background with a delay, before the server starts.
tokio::spawn(async{// Wait for 5 seconds before running the function to give
// server time to startup
tokio::time::sleep(std::time::Duration::from_secs(5)).await;startup::run_startup_actions().await;});
This now works, and actions execute successfully a few seconds after server starts.
But it definitely feels like I could probably do this in a way that doesn't introduce a possible race condition. That said, I felt 5 seconds was pretty generous.
Edit: I changed the implementation. Did some reading and found axum_server::Handle::listening() which I was able to leverage with minimal changes to make sure the action only runs after the handle is listening.
With that, it does work for me.
And the action runs successfully after server startup
And actions which do not have this enabled do not run at startup, as expected. So functionally I think it works.
Very welcome to changing how I do this, like I said I am not super familiar with this toolchain.
Edit:
I was also thinking (assuming this feature is desired, of course) that it may be necessary to implement some env/config option that disables this feature globally. Reason being that I'm not sure if there may be some way to bootloop your system by a broken action that causes core to restart. I'm not sure if that is possible, but would be quite annoying if it were. I suppose the 5 second delay could save them here.
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.
## 📋 Pull Request Information
**Original PR:** https://github.com/moghtech/komodo/pull/664
**Author:** [@bpbradley](https://github.com/bpbradley)
**Created:** 7/14/2025
**Status:** ✅ Merged
**Merged:** 7/28/2025
**Merged by:** [@mbecker20](https://github.com/mbecker20)
**Base:** `1.18.5` ← **Head:** `run_on_startup`
---
### 📝 Commits (2)
- [`fb8b325`](https://github.com/moghtech/komodo/commit/fb8b325a018bc915421dbb930dbfbc2c18fd7f61) Implement ability to run actions at startup
- [`482322c`](https://github.com/moghtech/komodo/commit/482322cd47fcdbb05d8c4a88aec9cc8a2ac912bc) run post-startup actions after server is listening
### 📊 Changes
**6 files changed** (+94 additions, -2 deletions)
<details>
<summary>View changed files</summary>
📝 `bin/core/src/main.rs` (+18 -1)
📝 `bin/core/src/startup.rs` (+51 -1)
📝 `client/core/rs/src/entities/action.rs` (+11 -0)
📝 `client/core/ts/src/types.ts` (+2 -0)
📝 `frontend/public/client/types.d.ts` (+2 -0)
📝 `frontend/src/components/resources/action/config.tsx` (+10 -0)
</details>
### 📄 Description
This feature adds a "Run On Startup" feature for Actions. When enabled, the action will be executed shortly after Komodo Core finishes loading.
Now first, I am experienced in C, not Rust, so forgive me if I did anything stupid. I mostly just borrowed from how actions were run in `schedule.rs` for borrowing the syntax / patterns to do what I wanted to do.
Originally, I added the startup actions in `startup.rs` at the end of the `on_startup` function (like this)
```rust
pub async fn on_startup() {
tokio::join!(
in_progress_update_cleanup(),
open_alert_cleanup(),
ensure_first_server_and_builder(),
clean_up_server_templates(),
run_startup_actions()
);
}
```
And this "worked", but the actions always failed with
```
Stderr
Download http://localhost:9120/client/lib.js
error: Import 'http://localhost:9120/client/lib.js' failed.
0: error sending request for url (http://localhost:9120/client/lib.js): client error (Connect): tcp connect error: Connection refused (os error 111): Connection refused (os error 111)
1: client error (Connect)
2: tcp connect error: Connection refused (os error 111)
3: Connection refused (os error 111)
at file:///action-cache/Wy9zMYzrte.ts:1:37
```
My reasoning was that this needed to occur _after_ the server becomes available here
```rust
if config.ssl_enabled {
info!("🔒 Core SSL Enabled");
rustls::crypto::ring::default_provider()
.install_default()
.expect("failed to install default rustls CryptoProvider");
info!("Komodo Core starting on https://{socket_addr}");
let ssl_config = RustlsConfig::from_pem_file(
&config.ssl_cert_file,
&config.ssl_key_file,
)
.await
.context("Invalid ssl cert / key")?;
axum_server::bind_rustls(socket_addr, ssl_config)
.serve(app)
.await
.context("failed to start https server")
} else {
info!("🔓 Core SSL Disabled");
info!("Komodo Core starting on http://{socket_addr}");
axum_server::bind(socket_addr)
.serve(app)
.await
.context("failed to start http server")
}
}
```
<del>
However, I don't really know how to get it to run after this in the way I was hoping.
So I sort of hacked it by just spawning the process to run the actions in the background with a delay, before the server starts.
```rust
tokio::spawn(async {
// Wait for 5 seconds before running the function to give
// server time to startup
tokio::time::sleep(std::time::Duration::from_secs(5)).await;
startup::run_startup_actions().await;
});
```
This now works, and actions execute successfully a few seconds after server starts.
But it definitely feels like I could probably do this in a way that doesn't introduce a possible race condition. That said, I felt 5 seconds was pretty generous.
</del>
Edit: I changed the implementation. Did some reading and found `axum_server::Handle::listening()` which I was able to leverage with minimal changes to make sure the action only runs after the handle is listening.
With that, it does work for me.
<img width="1295" height="327" alt="image" src="https://github.com/user-attachments/assets/91148841-c0c1-4d8a-8350-21e38abd31b5" />
And the action runs successfully after server startup
<img width="1271" height="638" alt="image" src="https://github.com/user-attachments/assets/c16a9772-2b8a-4515-b787-f9eb28a0589c" />
And actions which do not have this enabled do not run at startup, as expected. So functionally I think it works.
Very welcome to changing how I do this, like I said I am not super familiar with this toolchain.
Edit:
I was also thinking (assuming this feature is desired, of course) that it may be necessary to implement some env/config option that disables this feature globally. Reason being that I'm not sure if there may be some way to bootloop your system by a broken action that causes core to restart. I'm not sure if that is possible, but would be quite annoying if it were. ~~I suppose the 5 second delay could save them here.~~
---
<sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
📋 Pull Request Information
Original PR: https://github.com/moghtech/komodo/pull/664
Author: @bpbradley
Created: 7/14/2025
Status: ✅ Merged
Merged: 7/28/2025
Merged by: @mbecker20
Base:
1.18.5← Head:run_on_startup📝 Commits (2)
fb8b325Implement ability to run actions at startup482322crun post-startup actions after server is listening📊 Changes
6 files changed (+94 additions, -2 deletions)
View changed files
📝
bin/core/src/main.rs(+18 -1)📝
bin/core/src/startup.rs(+51 -1)📝
client/core/rs/src/entities/action.rs(+11 -0)📝
client/core/ts/src/types.ts(+2 -0)📝
frontend/public/client/types.d.ts(+2 -0)📝
frontend/src/components/resources/action/config.tsx(+10 -0)📄 Description
This feature adds a "Run On Startup" feature for Actions. When enabled, the action will be executed shortly after Komodo Core finishes loading.
Now first, I am experienced in C, not Rust, so forgive me if I did anything stupid. I mostly just borrowed from how actions were run in
schedule.rsfor borrowing the syntax / patterns to do what I wanted to do.Originally, I added the startup actions in
startup.rsat the end of theon_startupfunction (like this)And this "worked", but the actions always failed with
My reasoning was that this needed to occur after the server becomes available here
However, I don't really know how to get it to run after this in the way I was hoping.So I sort of hacked it by just spawning the process to run the actions in the background with a delay, before the server starts.
This now works, and actions execute successfully a few seconds after server starts.
But it definitely feels like I could probably do this in a way that doesn't introduce a possible race condition. That said, I felt 5 seconds was pretty generous.
Edit: I changed the implementation. Did some reading and found
axum_server::Handle::listening()which I was able to leverage with minimal changes to make sure the action only runs after the handle is listening.With that, it does work for me.
And the action runs successfully after server startup
And actions which do not have this enabled do not run at startup, as expected. So functionally I think it works.
Very welcome to changing how I do this, like I said I am not super familiar with this toolchain.
Edit:
I was also thinking (assuming this feature is desired, of course) that it may be necessary to implement some env/config option that disables this feature globally. Reason being that I'm not sure if there may be some way to bootloop your system by a broken action that causes core to restart. I'm not sure if that is possible, but would be quite annoying if it were.
I suppose the 5 second delay could save them here.🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.