Fix race conditions and execution order - Githubissues

qaisjp / go-discord-irc

The Discord and IRC bridge with puppets! An IRC user is created for each Discord user, messages from IRC seamlessly appear on Discord, and Discord mentions are automagically converted to and from IRC.

MIT License

113 stars 32 forks source link

Fix race conditions and execution order #95

Closed llmII closed 3 years ago

llmII commented 3 years ago

Fix: Race conditions and execution order issues

This should make use of the new features in go-ircevent so as to not cause panics from concurrent read & write to maps.
This should also make it where we don't need to reimplement nick tracking in go-discord-irc by making use of go-ircevent's features to insure our callbacks are called after/before state tracking has occured.
This should keep quits/kicks/parts from showing for puppeted nicks by maintaining correct order of execution for the corresponding events where we have more than one handler due to tracking puppets.

Most of this was separated out from #72. It is yet to be tested and is possible I'm doing RPC wrong (in which case please give me a pointer or 2).

EDIT: Tested, NICK/PART/JOIN working - figuring out QUIT.

EDIT 2: Tested, working completely (does require go.mod bump).

llmII commented 3 years ago

This needs go.mod bumped... going to do that on my branch. The latest version of qaisjp/go-ircevent includes a logic fix for STQUIT.

qaisjp commented 3 years ago

Although generally I think we may want to sync this nick data over from varys to the bridge, and use that synced data, instead of querying varys for each puppet.

llmII commented 3 years ago

Although generally I think we may want to sync this nick data over from varys to the bridge, and use that synced data, instead of querying varys for each puppet.

Not a bad idea, but in general that might require a way for varys to signal the bridge "ask me for data" or to send an update to the bridge (there is no guarantee that a puppet's nick won't change due to external influences).

llmII commented 3 years ago

Believe I understand the RPC bit a bit better now, first param to the call is a struct of function params, the second is the pointer to where to store the result. Have updated the code to make it more fit the style of go-discord-irc vs a "get something working" approach I took this morning as I worked to bring everything else up to speed. It's late here so I'll likely test this sometime tomorrow but expect it to work as it's basically the same code just written differently.

llmII commented 3 years ago

Tested and working again.