Use troupe crate
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.
Note that this would merge into development
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
Transientfront end stuff should probably bePermanent. -
SinkClient.sendnow "bubbles up the panic" (per a comment in the deletedactor.rs) by returning aboolinstead 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.
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.
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.
- Did you double-check the permanence choices I made? After making this PR I decided some of the
Transientfront end stuff should probably bePermanent.
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.
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 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.
:exclamation: Current head cb4d1c3 differs from pull request most recent head b0b55f4. Consider uploading reports for the commit b0b55f4 to get more accurate results
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
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
There is a conflict. I will resolve that error before merging.
Should I squash-rebase, or do you use the squash Github feature? I have a lot of junk commit messages.