modulatingforce/forcebot_rs

Fork 0

Routine.Start() to run it's execution body for given duration #47

Closed

modulatingforce wants to merge 1 commit from routine-start-issue into routines-functionality

modulatingforce commented

2024-03-27 11:40:25 -04:00

Owner

Raised from Routines Functionality PR being introduced in #40

Routine.Start() to run it's execution body for given duration

🔥High Priority as this is a blocker of the current Routine functionality

Functional Use Case :

As a Custom Module Developer, I create a new Custom Module
In the module, Related to a Routine object
- I define an async fn Routine Execution Body that the Routine will call during it's execution loop
- I construct a Routine by calling from() and passing RoutineAttr like RunOnce . I also pass the async fn
- If constructed successfully , I start() the Routine
In the module, Related to a BotCommand object
- I define a BotCommand that defines the above for the Routine object
To test , I can go Twitch Chat and issue the BotCommand . This should successfully create & start the routine

Smol Working Demo -

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=0fc9e09bc9d4d53ee492814a2914b4e8

The above Working Sample Code Demonstrates :

A Routine object with from() and start()
When calling the routine, the tokio::spawn is executed as defined

NOTE : There may be a few differences between working and code problem bot code

ISSUE

During Runtime at Botcommand run , there seems to be issues within the tokio:spawn reaching a point involving the following

inroutine.read().await.loopbody().await;

Refer to : #40 (comment)
The above line calls the defined async routine execution body

Logs & twitch observations :

Logs do show trace statements just before the above line , and within the tokio:spawn . However, logs also seem to suggest sometimes some of these log traces in tokio:spawn before that point are triggered, and sometimes they are not
- I believe this is suggesting that the tokio:spawn might be ending prematurely before allowing the above line to trigger?
There is no critical write locking issue . The Bot continues to be responsive in twitch

Plan of Action :

~~~~Will collaborate with others (tori uwu~~) on this current branch for possible working solutions~~~
~~Worst case: don't reinvent the wheel - look how others implement this probably common object in rust~~
Identify Problem Code and code recommendations
Live Tests afterwards
Consider units tests? (Or if unit tests should be passed to parent PR #40 ) - No Unit tests required

Raised from `Routines` Functionality PR being introduced in https://git.flake.sh/modulatingforce/forcebot_rs/pulls/40 `Routine.Start()` to run it's execution body for given duration 🔥High Priority as this is a blocker of the current `Routine` functionality # Functional Use Case : 1. As a Custom Module Developer, I create a new Custom Module 2. In the module, Related to a `Routine` object - I define an async fn Routine Execution Body that the Routine will call during it's execution loop - I construct a `Routine` by calling `from()` and passing `RoutineAttr` like `RunOnce` . I also pass the async fn - If constructed successfully , I `start()` the `Routine` 3. In the module, Related to a `BotCommand` object - I define a `BotCommand` that defines the above for the `Routine` object 4. To test , I can go Twitch Chat and issue the `BotCommand` . This should successfully create & start the routine --- ## Smol Working Demo - https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=0fc9e09bc9d4d53ee492814a2914b4e8 The above Working Sample Code Demonstrates : 1. A `Routine` object with `from()` and `start()` 2. When calling the routine, the `tokio::spawn` is executed as defined NOTE : There may be a few differences between working and code problem bot code --- # ISSUE During Runtime at `Botcommand` run , there seems to be issues within the `tokio:spawn` reaching a point involving the following ```rust inroutine.read().await.loopbody().await; ``` - Refer to : https://git.flake.sh/modulatingforce/forcebot_rs/pulls/40#issuecomment-776 - The above line calls the defined async routine execution body ## Logs & twitch observations : 1. Logs do show trace statements just before the above line , and within the `tokio:spawn` . However, logs also seem to suggest _sometimes_ some of these log traces in `tokio:spawn` before that point are triggered, and sometimes they are not - I believe this is suggesting that the `tokio:spawn` might be ending prematurely before allowing the above line to trigger? 2. There is no critical `write` locking issue . The Bot continues to be responsive in twitch --- # Plan of Action : - [x] ~~Will collaborate with others (tori uwu~) on this current branch for possible working solutions~~ - [x] ~~Worst case: don't reinvent the wheel - look how others implement this probably common object in rust~~ - [x] Identify Problem Code and code recommendations - [x] Live Tests afterwards - [x] Consider units tests? (Or if unit tests should be passed to parent PR https://git.flake.sh/modulatingforce/forcebot_rs/pulls/40 ) - No Unit tests required

modulatingforce added this to the Prototype 1.0 milestone

2024-03-27 11:40:25 -04:00

modulatingforce added the

Kind/Bug

Priority

High

labels

2024-03-27 11:40:25 -04:00

modulatingforce referenced this pull request

2024-03-27 11:44:27 -04:00

WIP: Basic Routine Functionality #40

modulatingforce commented

2024-03-27 11:46:10 -04:00

Author

Owner

For the related line in code, refer to

#40 (comment)

For the related line in code, refer to https://git.flake.sh/modulatingforce/forcebot_rs/pulls/40#issuecomment-776

modulatingforce added this to the Rust Learning project

2024-03-27 12:53:46 -04:00

modulatingforce referenced this pull request

2024-03-27 14:18:42 -04:00

WIP: Basic Routine Functionality #40

modulatingforce commented

2024-03-27 14:25:28 -04:00

Author

Owner

Possible Solution : Code Recommendation at Custom Module

Remove the following line from the custom module .

newr.clone().write().await.join_handle.take().expect("Issue with join handle").await.unwrap();

newr.clone().write().await.join_handle.take().expect("Issue with join handle").await.unwrap();

The above appears to be trying to handle & then take() the JoinHandle at Routine object .

I'm not sure if that is prematurely aborting the JoinHandle

Removing the above line ensures that as long as the BotInstance is continuing to run, the Routine's spawned tasks will run until completed or aborted

# Possible Solution : Code Recommendation at Custom Module Remove the following line from the custom module . ``` newr.clone().write().await.join_handle.take().expect("Issue with join handle").await.unwrap(); ``` https://git.flake.sh/modulatingforce/forcebot_rs/src/commit/b08d91af5d2c67a54f1921aee5640523c09aad22/src/custom/experimental/experiment003.rs#L193 The above appears to be trying to handle & then `take()` the `JoinHandle` at `Routine` object . - I'm not sure if that is prematurely aborting the `JoinHandle` Removing the above line ensures that as long as the `BotInstance` is continuing to run, the `Routine`'s spawned tasks will run until completed or aborted

modulatingforce added 1 commit

2024-03-27 14:56:39 -04:00

Merge branch 'routines-functionality' into routine-start-issue be00fe1d7e

modulatingforce commented

2024-03-27 15:21:53 -04:00

Author

Owner

Resolution Notes

Resolution Type : Code Change - Bot_Custom Code

Related Core Fix Commits : modulatingforce/forcebot_rs@be00fe1d7e fixes the issue

SOP Recommendations :

If similar Runtime issues are observed, review areas where JoinHandle is being await or handled . In the current case, removing a potentially unnecessary call to take() helped address the issue .
These Changes will usually be at Custom Code Level unless Core was recently change that involved the above type of change

Learning Experiences :

take() at JoinHandle may be (by design) Deallocating the JoinHandle, therefore acting to it similarly to an abort()
- I believe these were introduced into Custom Code to try to handle some borrowing related issues or test these out. We've determined take() is not required
I experimented with abort also . If required, the same Core Fix Commit has comments on working abort of JoinHandle at Custom Code level

# Resolution Notes **Resolution Type :** Code Change - Bot_Custom Code **Related Core Fix Commits :** https://git.flake.sh/modulatingforce/forcebot_rs/commit/be00fe1d7eeee5bf0ad0e1fdd2b606e183575d44 fixes the issue **SOP Recommendations :** - If similar Runtime issues are observed, review areas where `JoinHandle` is being `await` or handled . In the current case, removing a potentially unnecessary call to `take()` helped address the issue . - These Changes will usually be at Custom Code Level unless Core was recently change that involved the above type of change **Learning Experiences :** 1. `take()` at `JoinHandle` may be (by design) Deallocating the `JoinHandle`, therefore acting to it similarly to an `abort()` - I believe these were introduced into `Custom` Code to try to handle some borrowing related issues or test these out. We've determined `take()` is not required 2. I experimented with `abort` also . If required, the same Core Fix Commit has comments on working `abort` of `JoinHandle` at Custom Code level

modulatingforce changed title from ~~WIP: Routine.Start() to run it's execution body for given duration~~ to Routine.Start() to run it's execution body for given duration

2024-03-27 15:21:58 -04:00

modulatingforce self-assigned this

2024-03-27 15:22:16 -04:00

modulatingforce

2024-03-27 15:28:23 -04:00