[PR #664] [MERGED] Implement ability to run actions at startup #758

New Issue

GiteaMirror · 2025-10-31T15:21:01-05:00

GiteaMirror commented

2025-10-31 15:21:01 -05:00

📋 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)

fb8b325 Implement ability to run actions at startup
482322c run 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.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)

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

 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")
  }
}

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>

GiteaMirror added the pull-request label 2025-10-31 15:21:01 -05:00

GiteaMirror closed this issue

2025-10-31 15:21:01 -05:00

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/komodo#758