Use troupe crate #202

orblivion · 2023-12-09T04:17:08Z

It compiles at least. Seems like the core stuff were handlers for stores that should be permanent. The stuff in clients were created with different ids and such so they should be transient. Though looking again, I'm unsure about whether the ManagerState should have been permanent.

send now seems to return a boolean where it didn't before. Assuming the value implies success, I figured we may not want to ignore it, but I assume the panics I put in place are not the right answer.

orblivion · 2023-12-09T04:17:31Z

Note that this would merge into development

TylerBloom

This looks good so far. What else needs to be done?

TylerBloom · 2023-12-10T16:43:55Z

squire_core/src/state/accounts.rs

+use troupe::{
+    ActorBuilder,
+    ActorState,
+    Permanent,
+    Scheduler,
+    sink::{
+        SinkActor,
+        SinkClient,
+        permanent::Tracker,
+    },
+};


nit: You should be able to use a wildcard import for this.

Suggested change

use troupe::{

ActorBuilder,

ActorState,

Permanent,

Scheduler,

sink::{

SinkActor,

SinkClient,

permanent::Tracker,

},

};

use troupe::prelude::*

I see. I would have thought that wildcard is less preferable because it could clobber names. Though I'm guessing that Rust would tell you if that happened (unlike Python). Do you recommend it generally or just if I'm importing a ton of stuff like this?

Opinions on wildcard imports vary. You are correct that Rust will warn you about this (even between different versions of the same crate). But, generally speaking, if a crate has a prelude module, this module should be thought of as "tools you need to use this crate" and/or "things you are going to commonly import".

As a general rule, I usually only use wildcard imports on prelude modules or something similar.

TylerBloom · 2023-12-10T16:45:44Z

squire_core/src/state/boilerplate.rs

@@ -16,3 +16,14 @@ impl Debug for SessionCommand {
        }
    }
 }
+
+impl Debug for AccountCommand {


Not necessary for this PR, but I wonder if we could use the derive_more crates macros to generate this.

orblivion · 2023-12-11T17:10:00Z

This looks good so far. What else needs to be done?

Did you double-check the permanence choices I made? After making this PR I decided some of the Transient front end stuff should probably be Permanent.
SinkClient.send now "bubbles up the panic" (per a comment in the deleted actor.rs) by returning a bool instead of (). I figured we should handle it somehow but I didn't know how. As a placeholder I have it panic if it returns false. I doubt that's actually what you want. So I have to figure out a better response.

orblivion · 2023-12-11T18:45:37Z

Could you clarify - if an actor message send fails, what exactly happened? Should we just retry until it succeeds? (Should that retry just be wrapped in a helper?) I took a crash course on Erlang one time long ago but I think I have more to learn about the actor model.

orblivion · 2023-12-11T18:53:32Z

squire_sdk/src/server/tournaments.rs

-    state.handle_new_onlooker(id, user, ws).await;
+    if !state.handle_new_onlooker(id, user, ws).await {
+        panic!("TODO what if this fails")
+    }


By the point it gets here, we've already assumed that AnyUser::convert returned Ok(...), so it seems we're already ready to panic. Should we just panic here? Does the router handle panics nicely?

Wait that's not right. It's not panicking in the case of not Ok(token), it's just returning. So I should probably silently fail like before, then, right?

orblivion · 2023-12-11T19:03:03Z

squire_sdk/src/server/gathering/hall.rs

@@ -85,7 +94,9 @@ where
        match msg {
            GatheringHallMessage::NewGathering(id) => self.process_new_gathering(id).await,
            GatheringHallMessage::NewConnection(id, user, ws) => {
-                self.process_new_onlooker(id, user, ws).await
+                if !self.process_new_onlooker(id, user, ws).await {
+                    panic!("TODO what if this fails")


It seems that this is the handler for an event fired off by this function call:

https://github.com/SquireTournamentServices/SquireCore/pull/202/files#diff-40dc5ead6a1b57fd7eb11a9736bf00f2ebf2f32b97bb5ea994dc2eaea1d67a58R110

If the above event firing fails and we never get here, might panic, and maybe the router handles it (as I mentioned in a comment there). But what if this message send fails? I'd think we'd want to propagate that failure back to the router, but I don't think we can anymore. But from what I remember from Erlang, the actor model is supposed to be tolerant of errors. So I'm not really sure what to do.

I guess before I put this in, you were effectively ignoring the errors anyway. Should I just go back to that?

From another thread:

The only time a message can fail is when a permanent actor has panicked.

Okay that's something I hadn't internalized. I see that track waits for a response, and will panic if the actor is permanent and panics (not sure about transient actors that panic) whereas send fires and forgets, ignoring(?) actor panics.

With that in mind, it seems that this panic would be ignored?

self.gatherings .send(GatheringHallMessage::NewConnection(id, user, ws))

As well as the panics below in GatheringHallMessage::Persist since they're scheduled with a delay:

scheduler.schedule( Instant::now() + Duration::from_secs(5), GatheringHallMessage::Persist, );

Are these actually okay to ignore?

orblivion · 2023-12-11T19:15:48Z

squire_core/src/state/mod.rs

-        let tourns = ActorClient::builder(TournPersister::new(tourn_db.clone())).launch();
-        let gatherings = ActorBuilder::new(GatheringHall::new(tourns.clone())).launch();
+        let tourns = ActorBuilder::new(TournPersister::new(tourn_db.clone())).launch();
+        let gatherings = ActorBuilder::new(GatheringHall::<TournPersister>::new(tourns.clone())).launch();
        AppState {


So just to be sure of my reasoning here: it looks like sessions, accounts, and gatherings are clients attached the app state, so those handlers should be Permanent. I think that tourns stays attached to gatherings, which means that that should also be Permanent.

Correct. All of those should be permanent. The only actors that should be transient are the Gatherings, which are internally managed by the GatheringHall actor.

orblivion · 2023-12-11T19:21:50Z

squire_sdk/src/client/network.rs

@@ -61,7 +66,11 @@ pub enum NetworkCommand {

 #[async_trait]
 impl ActorState for NetworkState {
+    type Permanence = Transient;


NetworkState attaches to a SquireClient which is created at the top level of main. I guess it should be Permanent.

(I initially thought it was a per-request sort of thing because I misunderstood what url was)

Yes, there is no reason for this to fail.

orblivion · 2023-12-11T19:24:43Z

squire_sdk/src/client/tournaments.rs

@@ -24,7 +32,7 @@ use crate::{
 /// A container for the channels used to communicate with the tournament management task.
 #[derive(Debug, Clone)]
 pub struct TournsClient {
-    client: ActorClient<ManagerState>,
+    client: ActorClient<Transient, ManagementCommand>,


Wait, ActorClient? How did this compile? Maybe the front end doesn't compile when you run cargo shuttle run?

The troupe actor model is built with compiling to WASM in mind. Both the front and back ends used it.

Sorry I was rather unclear - My point is that ActorClient is the old name that you used in actor.rs, which became SinkClient etc. I'm confused as to how cargo shuttle run started without complaining about this. My hypothesis was that it wasn't compiling the front end (which means I probably have plenty more errors to fix).

orblivion · 2023-12-11T21:25:39Z

I think ManagerState clients should be changed to Permanent for the same reason as NetworkState.

Gathering (in the client) however seems like it may want to stay as Transient, since you spawn them and add them to a collection.

But I'm realizing now that the type checker should correct me if I'm getting permanence wrong. I just need to be able to compile the client.

TylerBloom · 2023-12-11T23:53:41Z

Did you double-check the permanence choices I made? After making this PR I decided some of the Transient front end stuff should probably be Permanent.

Hmm, basically all actors we had were permanent except for the Gathering. @akbulutdora implemented a feature to have the Gathering and GatheringHall communicate was the gathering was going to end. That should probably be taken into consideration.

TylerBloom · 2023-12-11T23:57:16Z

Could you clarify - if an actor message send fails, what exactly happened? Should we just retry until it succeeds? (Should that retry just be wrapped in a helper?) I took a crash course on Erlang one time long ago but I think I have more to learn about the actor model.

Sure. The only time a message can fail is when a permanent actor has panicked. Messages to and from an actor use in-memory channels, not something like interprocess communication, etc. Under the current model, this is an unrecoverable error from an outsider's perspective. We do not have something like a manager model yet.

codecov · 2023-12-20T20:59:05Z

Codecov Report

Attention: 50 lines in your changes are missing coverage. Please review.

Comparison is base (bf0eac7) 30.25% compared to head (cb4d1c3) 29.28%.
Report is 3 commits behind head on development.

❗ Current head cb4d1c3 differs from pull request most recent head b0b55f4. Consider uploading reports for the commit b0b55f4 to get more accurate results

Files	Patch %	Lines
squire_sdk/src/client/tournaments.rs	0.00%	14 Missing ⚠️
squire_sdk/src/server/gathering/hall.rs	9.09%	10 Missing ⚠️
squire_core/src/state/boilerplate.rs	0.00%	6 Missing ⚠️
squire_core/src/state/session.rs	14.28%	6 Missing ⚠️
squire_sdk/src/client/network.rs	0.00%	4 Missing ⚠️
squire_core/src/state/mod.rs	40.00%	3 Missing ⚠️
squire_sdk/src/server/gathering/mod.rs	0.00%	3 Missing ⚠️
squire_core/src/state/accounts.rs	33.33%	2 Missing ⚠️
squire_sdk/src/server/tournaments.rs	0.00%	2 Missing ⚠️

Additional details and impacted files

@@               Coverage Diff               @@
##           development     #202      +/-   ##
===============================================
- Coverage        30.25%   29.28%   -0.98%     
===============================================
  Files               77       76       -1     
  Lines             4022     3961      -61     
===============================================
- Hits              1217     1160      -57     
+ Misses            2805     2801       -4

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

…nment

orblivion · 2024-01-04T19:59:43Z

squire_sdk/Cargo.toml

@@ -63,6 +63,8 @@ headers = { version = "0.4", optional = true }
 # To be moved
 hashbag = { version = "0.1.11", features = ["serde"] }
 derive_more = "0.99.17"
+hyper = "1.0"


The history of this one is a bit weird. Within the history of development, we see hyper = "0.14" added and removed.

Should this line be here in this PR?

Ya, the history is a bit weird, but this line is fine. This change is needed regardless.

orblivion · 2024-01-04T20:34:39Z

squire_sdk/src/client/tournaments.rs

@@ -239,7 +259,7 @@ impl ManagerState {
                    let (sink, stream) = ws.split();
                    let (broad, sub) = watch_channel(());
                    entry.get_mut().comm = Some((sink, broad));
-                    scheduler.add_stream(stream);
+                    scheduler.attach_stream(stream.fuse());


Seems like .fuse() showed up during the rebase. I tried removing it, and I get a type error in the front end code. I guess this is something I would have seen if I had compiled the front end before the rebase.

But the weird thing is that .fuse() is also called within troupe, in attach_stream_inner. Is this correct, and is it necessary?

This is really more of an issue with troupe. I remember writing this function signature and was torn on this question. fuse adds (basically) no overhead, so it isn't a problem. You need to give attached_stream a fused stream because I want the caller to acknowledge that the stream is capable of terminating.

Internally, the second call to fuse can be gotten rid of. If you would like, you can open a PR on the troupe repo to address this.

orblivion · 2024-01-04T21:03:38Z

squire_sdk/src/server/gathering/hall.rs

@@ -64,18 +65,23 @@ pub enum GatheringHallMessage {
 /// through message passing and tokio tasks.
 #[derive(Debug)]
 pub struct GatheringHall<P: ActorState<Message = PersistMessage>> {


Looking at this again and thinking about it, it seems like we can just remove this type restriction. (That it requires a phantom should have been a sign). I'm going to push a change that removes it, lmk what you think.

You added it here:

f5a8189

orblivion · 2024-01-04T22:39:11Z

squire_sdk/src/server/gathering/hall.rs

-                self.process_new_onlooker(id, user, ws).await
+                if !self.process_new_onlooker(id, user, ws).await {
+                    panic!("process_new_onlooker failed")
+                }


So now I have to decide on these panics I added. I think the right call is context specific. But I will say that if ignore the error instead, it won't be a regression (and as such maybe we can handle it in a separate PR). The question is about whether to handle a failure to send now that we have access to it (bool return value of send()), and whether panic is the right option.

process_new_onlooker gets or inits a gathering. Supposing we get one and it fails to send. Rather than panic, it seems like maybe what needs to happen is that these gatherings should be removed from the collection? Since they've panicked or shut down?

But I will say that if ignore the error instead, it won't be a regression
This is correct. This function returns false when the user attempts to connect to a tournament that has already shutdown for whatever reason. This is not an unrecoverable error for the GatheringHall. A panic here means, amount other things, that all tournaments will fail to get new connections.

I think the best solution for now is to just ignore this error. I'm working to refactor most of the websocket management logic so that a user only ever has one WS open at a time. That will address most of the open questions around this problem.

orblivion · 2024-01-04T22:39:49Z

squire_sdk/src/server/gathering/hall.rs

-                    sender.send(msg);
+                    if !sender.send(msg) {
+                        panic!("GatheringMessage::GetTournament failed")
+                    }


This is similar, maybe a gathering panicked or shut down. But this is a failure to write to disk. That's pretty bad, right?

Similar to what I was saying before. A panic for Permanent actors should be reserved for errors that are completely unrecoverable. If we failed to get a copy of the tournament, that's fine. The tournament just shutdown. That should not stop the entire tournament management system.

squire_sdk/src/server/gathering/hall.rs

TylerBloom

This all looks mostly good. There are two panics in the GatheringHall that should be removed. After that, I'll happily merge this.

TylerBloom · 2024-01-06T20:34:21Z

There is a conflict. I will resolve that error before merging.

orblivion · 2024-01-08T15:46:47Z

Should I squash-rebase, or do you use the squash Github feature? I have a lot of junk commit messages.

* Don't panic so frivolously * Remove type restriction on GatheringHall (we could have done this before the troupe crate IMO) * Drop a couple drops that we no longer need thanks to troupe doing it for us * Undo a weird commit that snuck in somehow via rebase * Derive/Implement `Debug` for a few things that we now need

TylerBloom reviewed Dec 10, 2023

View reviewed changes

orblivion commented Dec 11, 2023

View reviewed changes

TylerBloom force-pushed the development branch from 2f8734c to e73e454 Compare December 20, 2023 20:34

TylerBloom force-pushed the development-troupe branch from 4d7a7d3 to dfd9e48 Compare December 20, 2023 20:51

TylerBloom force-pushed the development branch 3 times, most recently from e393898 to bf0eac7 Compare December 21, 2023 19:17

TylerBloom and others added 10 commits December 21, 2023 14:18

A basic but functional logic to the login page

b50b228

Fixed client general request bug. Fixed upload tournament API misalig…

058bc05

…nment

WIP - use troupe crate

33c2c4d

WIP ActorClient->SinkClient - forgot a few

94664ea

WIP NetworkClient should be Permanent

1ef180e

WIP Tourn/Manager is Permanent

17d2231

WIP - More concise imports

f2f291e

WIP Panic in case of a certain send actor message failure

68534b5

WIP better panic messages

edb11fa

Rebase clean up

78f4b0c

TylerBloom force-pushed the development-troupe branch from dfd9e48 to 78f4b0c Compare December 21, 2023 19:19

orblivion commented Jan 4, 2024

View reviewed changes

squire_sdk/src/server/gathering/hall.rs Show resolved Hide resolved

TylerBloom requested changes Jan 6, 2024

View reviewed changes

orblivion changed the title ~~WIP - use troupe crate~~ Use troupe crate Jan 8, 2024

TylerBloom approved these changes Jan 9, 2024

View reviewed changes

orblivion force-pushed the development-troupe branch from de8a79d to b0b55f4 Compare January 11, 2024 17:28

Use troupe crate #202

Are you sure you want to change the base?

Use troupe crate #202

Conversation

orblivion commented Dec 9, 2023

orblivion commented Dec 9, 2023

TylerBloom left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

orblivion commented Dec 11, 2023

orblivion commented Dec 11, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

orblivion Dec 11, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

orblivion commented Dec 11, 2023 • edited Loading

TylerBloom commented Dec 11, 2023

TylerBloom commented Dec 11, 2023

codecov bot commented Dec 20, 2023 • edited Loading

Codecov Report

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TylerBloom left a comment

Choose a reason for hiding this comment

TylerBloom commented Jan 6, 2024

orblivion commented Jan 8, 2024

orblivion Dec 11, 2023 •

edited

Loading

orblivion commented Dec 11, 2023 •

edited

Loading

codecov bot commented Dec 20, 2023 •

edited

Loading