Possible MAS incompat: /login on every startup causes "olm account is marked as shared" crash loop — would POSTMOOGLE_TOKEN help?

[yncyrydybyl]

⚠️ This is a diagnostic guess, not a confirmed root cause. Posting it because I think the symptoms point somewhere useful, but I haven't proven the MAS-side claim and would value a sanity check from someone who knows postmoogle's internals better.

Symptom

Running postmoogle against a homeserver fronted by Matrix Authentication Service (MAS), the bridge eventually enters a crash loop:

FTL cannot initialize matrix bot
   error="olm account is marked as shared, keys seem to have disappeared from the server"

It's recurred at least twice on my server. Manual workaround that revives it: stop the service, UPDATE crypto_account SET shared = false, start it again. This works for hours/days, then breaks again.

What I observed (facts)

• Postmoogle is configured with POSTMOOGLE_LOGIN + POSTMOOGLE_PASSWORD.
• In MAS's compat_sessions table, every postmoogle startup creates a new row for the same device_id, and the previous row gets finished_at set. During the crash loop this happens dozens of times per minute.
• Source-reading in cmd/postmoogle/main.go shows linkpearl.New() is called with Login+Password only.
• go-linkpearl's resolveCredentials() already supports a Token field — when set, it skips /login and just calls /account/whoami.

What I'm guessing (unverified)

• That MAS purges the device's server-side e2e keys when it finishes a compat session, and that this is why postmoogle's locally-stored `shared=true` becomes a lie. I have not confirmed this in MAS source or by inspecting Synapse's device-key tables before/after a session finish. It could just as easily be something else entirely (some other component clearing keys, a postmoogle data-volume issue I haven't spotted, a Synapse cleanup job, etc.).
• That switching postmoogle to token auth would fix it. Plausible because token auth in linkpearl avoids opening a new compat session, if my MAS theory is right. If it's wrong, this change won't help.

Proposed change (if the theory holds)

Plumb a `Token` field through postmoogle's config so it can use linkpearl's existing token path:

1. Add `Token string` to `internal/config/types.go` `Config{}`.
2. Read `env.String("token", defaultConfig.Token)` in `internal/config/config.go`.
3. Pass `Token: cfg.Token` to `linkpearl.New(&linkpearl.Config{...})` in `cmd/postmoogle/main.go` (~L105).

Operators on MAS could then issue a long-lived compat token (`mas-cli manage issue-compatibility-token`) and drop `POSTMOOGLE_PASSWORD`.

Questions

• Has anyone else seen this with MAS?
• Does the `crypto_account.shared` flow assume the device's keys are durable on the server side once published? (If so, that assumption breaks under MAS as I've described it — but again, if my theory is right.)
• Would you accept a PR adding `POSTMOOGLE_TOKEN` even if it turns out not to fix this specific issue, or would you prefer the underlying cause be confirmed first?

Happy to dig deeper (e.g. tail Synapse + MAS logs around a failure) if it'd help.

[spantaleev]

I've sometimes hit this issue as well.
I've tried digging around (including in MAS source code), but haven't been able to really figure it out yet.

Is Synapse running with workers for you? For now, my experience shows that this is only reproducible when Synapse workers are also involved (not just MAS). I've dug into Synapse's source code as well, but.. haven't been able to get any clues.

Let us know if your setup also involves Synapse workers or if it's just regular non-worker Synapse + MAS!

[yncyrydybyl]

Let us know if your setup also involves Synapse workers or if it's just regular non-worker Synapse + MAS!

Yes, I have workers enabled.

matrix_synapse_workers_enabled: true
matrix_synapse_workers_preset: one-of-each