-
-
Notifications
You must be signed in to change notification settings - Fork 69
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: Add AccountDataStore #23
Conversation
I've been wondering whether it would be a good idea to change func NewClient(... eventType string) *Client {
c := &Client{
AccessToken: accessToken,
UserAgent: "mautrix-go " + Version,
HomeserverURL: hsURL,
UserID: userID,
Client: http.DefaultClient,
Prefix: URLPath{"_matrix", "client", "r0"},
Syncer: NewDefaultSyncer(),
}, nil
store = NewAccountDataStore(eventType, c)
c.Store = store
return c, nil I think the default behaviour you'd get with AccountDataStore is more inline with what people, especially newcomers, would expect. I.e the bot doesn't react to events "in the past". |
In Right now the code ignores the |
I'm also wondering if this change might be a good reason to drop the |
@tulir Mind taking a look at this? Based on my understanding, I've added a check to Save and Load to ensure the user ID we're manipulating data for is the same as the client that was created for it. The reason for it is that I think this should only be used with bots, because if it's used with an appservice that would potentially result in us needing to store something like a |
I've tried the current implementation out with a bot of mine, seems to work quite well. |
I think I might be wrong about this working. I'm trying this against a dendrite, and the server logs go completely nuts. Might be a thing in dendrite, but it seems wrong somehow. I seem to end up in a cycle of
|
It turns out this was caused by Dendrite, it doesn't appear to have account data filters working yet. Testing this against a Synpase works as expected. |
The AccountDataStore leverages a user's account data to load/save the next_batch token, while retaining the InMemoryStore behaviour for saving filters and room state. This permits a client to know which messages it has seen/processed when (re)syncing, for example after a bot is restarted. This isn't possible with the InMemoryStore since the token would be lost when the process is restarted resulting in answering to messages we might have already handled before. An otherwise stateless client can now use the home server as its persistent data store for the next_batch token, instead of having to use a file or database of its own.
@daenney What are you supposed to do with the filter created by |
The AcoountDataStore uses the account data to store the sync token. If you don't filter it out, you'll get into writing the sync token, which causes a new event to appear on /sync and you end up in a sync storm. So you want to create a filter to filter out your custom event type, and you want to tell the AccountDataStore to use that event type to store the sync token. Once you have the filter, all you need to do is register it:
And then pass that same event type into |
Is it possible to get an example with this NewAccountDataStore function? |
The
AccountDataStore
leverages a user's account data to load/save thenext_batch
token, while retaining theInMemoryStore
behaviour for saving filters and room state.This permits a client to know which messages it has seen/processed when (re)syncing, for example after a bot is restarted. This isn't possible with the
InMemoryStore
since the token would be lost when the process is restarted resulting in answering to messages we might have already handled before.An otherwise stateless client can now use the home server as its persistent data store for the
next_batch
token, instead of having to use a file or database of its own.