Twitter bridge creates dozens of portal invites/space children on login even when trying to limit initial sync

[PinkDraconian]

Summary

On a self-hosted Synapse setup, logging into mautrix-twitter creates a large number of Twitter child rooms/invites
immediately, instead of limiting initial room creation to a small recent subset.

I was trying to achieve this behavior:

• create only a few recent rooms on initial login
• create older chats only when new messages arrive later

That did not happen. The bridge eagerly created a large Twitter space tree and many invite-only/ghost rooms
immediately after login.

Environment

• Homeserver: Synapse
• Bridge: mautrix-twitter
• Deployment: Docker
• Personal filtering spaces: enabled
• Backfill: disabled
• Conversation sync limit in config: set low (5 during testing)

What I expected

After login, I expected:

• at most a handful of Twitter rooms to be created
• a Twitter space containing only those few rooms
• older chats to appear only on fresh incoming activity

Additional behavior seen in logs

Relevant patterns from logs:

• initial XChat inbox fetch still processed a lot of conversation/user material
• after login, the bridge began fetching per-conversation data for many missing portals
• repeated calls to GetConversationData hit X rate limits:
  • HTTP 429: Rate limit exceeded
• log lines included:
  • Portal missing; fetching conversation data
  • Failed to ensure portal and key exist before handling XChat message
  • Failed to fetch conversation data
  • Skipping Matrix room creation due to initial conversation sync limit

So even when room creation was artificially capped, the bridge still eagerly drove a lot of portal/user/conversation
activity and space child churn.

Why this seems wrong

From an admin/operator point of view, a low initial sync cap should prevent the bridge from flooding the homeserver/
client with rooms/invites/space children during first login.

Instead, the current behavior appears to eagerly materialize a much larger graph of chats/users than the configured
limit suggests.

Impact

• floods the client with invite notifications
• creates large numbers of ghost users
• populates the Twitter space with many stale/unnamed child rooms
• causes unnecessary churn on Synapse
• hits remote rate limits (429) during bootstrap

Questions

• Is there currently any supported way to make mautrix-twitter do truly lazy portal creation?
• Should conversation_sync_limit be expected to cap initial visible portal/space creation?
• Is the bridge expected to create m.space.child entries for rooms that are not fully materialized yet?
• Is this a bug in the initial login/bootstrap flow, or intended behavior?

Reproduction outline

1. Set up Synapse + mautrix-twitter
2. Enable personal filtering spaces
3. Set conversation_sync_limit to a low value like 5
4. Log into X
5. Observe:
   • Twitter space appears
   • many room invites arrive
   • many child rooms are attached to the Twitter space
   • ghost users are created far beyond the intended cap

Notes

I ended up fully purging the Twitter bridge from my server because it did not behave like a lazy/on-demand bridge
during initial login.