if the user exists in the database but was not loaded on daemon startup,
attempt to load it from the database before instructing the operator to
restart the daemon.
---
server.go | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/server.go b/server.go
index 7d1d305..79c19f2 100644
--- a/server.go+++ b/server.go
@@ -390,6 +390,13 @@ func (s *Server) forEachUser(f func(*user)) {
func (s *Server) getUser(name string) *user {
s.lock.Lock()
u := s.users[name]
+ if u == nil {+ dbu, err := s.db.GetUser(context.TODO(), name)+ if err == nil {+ s.addUserLocked(dbu)+ u = s.users[name]+ }+ } s.lock.Unlock()
return u
}
--
2.37.3
--
Lauri Tirkkonen | lotheac @ IRCnet
On Mon, Jan 16 2023 10:51:33 +0000, Simon Ser wrote:
> Thanks for the patch, but this feature has already been rejected in the> past:> > https://lists.sr.ht/~emersion/soju-dev/patches/25249> https://lists.sr.ht/~emersion/soju-dev/patches/26042
Ah, I see, thanks for the explanation, and sorry for the noise. I will
maintain a local patch for this then.
Out of curiosity, is the current behavior not problematic for
chat.sr.ht? I would imagine larger deployments would generally not want
to restart the bouncer :)
--
Lauri Tirkkonen | lotheac @ IRCnet
On Monday, January 16th, 2023 at 11:54, Lauri Tirkkonen <lauri@hacktheplanet.fi> wrote:
> Out of curiosity, is the current behavior not problematic for> chat.sr.ht? I would imagine larger deployments would generally not want> to restart the bouncer :)
chat.sr.ht does not rely on sojuctl to add new users to the bouncer.
This issue only happens when sojuctl is used.
(The plan to fix this mess is to make sojuctl talk to soju instead of
mutating the DB.)