Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Store doesn't work if old events are ignored #22

Open
rkfg opened this issue Dec 16, 2020 · 0 comments
Open

Store doesn't work if old events are ignored #22

rkfg opened this issue Dec 16, 2020 · 0 comments

Comments

@rkfg
Copy link

rkfg commented Dec 16, 2020

I'd like to use client.Store to inspect the joined rooms and memebers without sending explicit requests that are prone to race conditions. However, I also need my bot not to answer to old messages so I use mautrix.OldEventIgnorer for that purpose like this:

var oei mautrix.OldEventIgnorer
oei.Register(client.Syncer.(mautrix.ExtensibleSyncer))

Then I register store updates:

client.Syncer.(*mautrix.DefaultSyncer).OnEvent(client.Store.(*mautrix.InMemoryStore).UpdateState)

Then I access the room list later after sync (in response to a user command) like this:

client.Store.(*mautrix.InMemoryStore).Rooms

And this map is empty because the initial sync gets skipped completely according to the OldEventIgnorer logic. The bot will only update the room states for new rooms that it joins after launch but not for everything that happened before. Is there any way to make it work?

PS: for now I made it work with this simple handler:

func skipOldMessages(resp *mautrix.RespSync, since string) bool {
	if since != "" {
		return true
	}
	for id, r := range resp.Rooms.Join {
		events := []*event.Event{}
		for _, e := range r.Timeline.Events {
			if e.Type.Class != event.MessageEventType {
				events = append(events, e)
			}
		}
		r.Timeline.Events = events
		resp.Rooms.Join[id] = r
	}
	return true
}

It simply removes all message events from the initial sync but leaves everything else intact so the other handlers can populate the initial state. It can't handle more complex situations when the bot leaves and rejoins later (unlike the vanilla implementation) but currently I don't need this functionality. Maybe these two approaches can be combined?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant