mautrix bridge backfill cursors are one-way
Configuring a mautrix bridge (whatsapp, imessage, linkedin, etc.) where initial sync ran with an imperfect config that affects how historical messages get attributed.
Once a mautrix bridge does its initial portal sync and backfill, the per-portal cursor advances monotonically and the historical messages it produced are baked in. If you discover a misconfig AFTER first sync — e.g., double-puppeting wasn't set up so outgoing messages were silently dropped from backfill, or backfill.enabled was false, or your displayname template was wrong — there is NO way to re-pull that history. mautrix-whatsapp has !wa sync-portal, mautrix-imessage does NOT, and neither has a portal-level cursor reset. The only nuclear options are: (a) delete the portal's row from the bridge's SQLite db (loses room continuity in Element since a new portal gets a new room ID), or (b) full logout/login (re-pulls everything for ALL portals, expensive). Going forward stays correct; the past is stuck with whatever state your config had at first sync.
Before the first pair-and-sync of a mautrix bridge, audit at least these three things in config.yaml: (1) double_puppet.secrets is populated AND login-matrix has been confirmed in the management room — otherwise outgoing messages are missing from backfill forever; (2) backfill.enabled / initial_limit / max_age_days set to what you actually want — not the defaults; (3) displayname_template uses fields that actually exist in your bridge's version (check the comments above the template in the example config, NOT upstream docs which lag the megabridge rewrites). Get all three right BEFORE scanning the QR / pasting the cookie.