I don't receive message from Signal anymore

[Thatoo]

The bridge (double puppeting) was working well till recently. One of the user who has registered his Matrix account as his primary device don't face any issue. Everything is still working well for him. However, I registered my matrix account as a secondary device and unfortunately, messages from Signal suddenly stop reaching my matrix account. I can still send messages from my Matrix account and my Signal contact get my messages but I don't get their answer in y matrix account. If I look at logs, sudo tail -f -n 100 /var/log/mautrix_signal/mautrix_signal.log or with grep transactions /var/log/matrix-synapse/homeserver.log There are logs about my messages sent from Matrix but no traces at all of messages from Signal...

I did the logout command and then I did link SignalMatrixBridge command but it didn't change anything to my issue.

Do you have any idea about what I could do?

Here is the content of our config.yaml mautrix-signal bridge if it helps.

# Homeserver details
homeserver:
    # The address that this appservice can use to connect to the homeserver.
    address: https://matrix.MYDOMAIN.fr
    # The domain of the homeserver (for MXIDs, etc).
    domain: MYDOMAIN.fr
    # Whether or not to verify the SSL certificate of the homeserver.
    # Only applies if address starts with https://
    verify_ssl: true
    # What software is the homeserver running?
    # Standard Matrix homeservers like Synapse, Dendrite and Conduit should just use "standard" here.
    software: standard
    # Number of retries for all HTTP requests if the homeserver isn't reachable.
    http_retry_count: 4
    # The URL to push real-time bridge status to.
    # If set, the bridge will make POST requests to this URL whenever a user's Signal connection state changes.
    # The bridge will use the appservice as_token to authorize requests.
    status_endpoint:
    # Endpoint for reporting per-message status.
    message_send_checkpoint_endpoint:
    # Maximum number of simultaneous HTTP connections to the homeserver.
    connection_limit: 100
    # Whether asynchronous uploads via MSC2246 should be enabled for media.
    # Requires a media repo that supports MSC2246.
    async_media: false

# Application service host/registration related details
# Changing these values requires regeneration of the registration.
appservice:
    # The address that the homeserver can use to connect to this appservice.
    address: http://localhost:8449
    # When using https:// the TLS certificate and key files for the address.
    tls_cert: false
    tls_key: false

    # The hostname and port where this appservice should listen.
    hostname: 0.0.0.0
    port: 8449
    # The maximum body size of appservice API requests (from the homeserver) in mebibytes
    # Usually 1 is enough, but on high-traffic bridges you might need to increase this to avoid 413s
    max_body_size: 1

    # The full URI to the database. SQLite and Postgres are supported.
    # Format examples:
    #   SQLite:   sqlite:///filename.db
    #   Postgres: postgres://username:password@hostname/dbname
    database: postgres://mautrix_signal:PSQLPWD@localhost:5432/mautrix_signal
    # Additional arguments for asyncpg.create_pool() or sqlite3.connect()
    # https://magicstack.github.io/asyncpg/current/api/index.html#asyncpg.pool.create_pool
    # https://docs.python.org/3/library/sqlite3.html#sqlite3.connect
    # For sqlite, min_size is used as the connection thread pool size and max_size is ignored.
    # Additionally, SQLite supports init_commands as an array of SQL queries to run on connect (e.g. to set PRAGMAs).
    database_opts:
        min_size: 5
        max_size: 10
    id: signalbot
    # Username of the appservice bot.
    bot_username: signalbot
    # Display name and avatar for bot. Set to "remove" to remove display name/avatar, leave empty
    # to leave display name/avatar as-is.
    bot_displayname: Signal bridge bot
    bot_avatar: mxc://maunium.net/wPJgTQbZOtpBFmDNkiNEMDUp

    # Whether or not to receive ephemeral events via appservice transactions.
    # Requires MSC2409 support (i.e. Synapse 1.22+).
    # You should disable bridge -> sync_with_custom_puppets when this is enabled.
    ephemeral_events: false

    # Authentication tokens for AS <-> HS communication. Autogenerated; do not modify.
    as_token: XXXXXXXXX-YYYYYYY
    hs_token: ZZZZZZ-TTTTTTTTT

# Prometheus telemetry config. Requires prometheus-client to be installed.
metrics:
    enabled: false
    listen_port: 8000

# Manhole config.
manhole:
    # Whether or not opening the manhole is allowed.
    enabled: false
    # The path for the unix socket.
    path: /var/tmp/mautrix-signal.manhole
    # The list of UIDs who can be added to the whitelist.
    # If empty, any UIDs can be specified in the open-manhole command.
    whitelist:
    - 0
signal:
    # Path to signald unix socket
    socket_path: /var/run/signald/signald.sock
    # Directory for temp files when sending files to Signal. This should be an
    # absolute path that signald can read. For attachments in the other direction,
    # make sure signald is configured to use an absolute path as the data directory.
    outgoing_attachment_dir: /tmp
    # Directory where signald stores avatars for groups.
    avatar_dir: ~/.config/signald/avatars
    # Directory where signald stores auth data. Used to delete data when logging out.
    data_dir: ~/.config/signald/data
    # Whether or not unknown signald accounts should be deleted when the bridge is started.
    # When this is enabled, any UserInUse errors should be resolved by restarting the bridge.
    delete_unknown_accounts_on_start: false
    # Whether or not message attachments should be removed from disk after they're bridged.
    remove_file_after_handling: true
    # Whether or not users can register a primary device
    registration_enabled: true
    # Whether or not to enable disappearing messages in groups. If enabled, then the expiration
    # time of the messages will be determined by the first users to read the message, rather
    # than individually. If the bridge has a single user, this can be turned on safely.
    enable_disappearing_messages_in_groups: false

# Bridge config
bridge:
    # Localpart template of MXIDs for Signal users.
    # {userid} is replaced with the UUID of the Signal user.
    username_template: sg_{userid}
    # Displayname template for Signal users.
    # {displayname} is replaced with the displayname of the Signal user, which is the first
    # available variable in displayname_preference. The variables in displayname_preference
    # can also be used here directly.
    displayname_template: '{displayname} (SG)'
    # Whether or not contact list displaynames should be used.
    # Possible values: disallow, allow, prefer
    #
    # Multi-user instances are recommended to disallow contact list names, as otherwise there can
    # be conflicts between names from different users' contact lists.
    contact_list_names: disallow
    # Available variables: full_name, first_name, last_name, phone, uuid
    displayname_preference:
    - full_name
    - phone
    autocreate_group_portal: true
    # Whether or not to create portals for all contacts on login/connect.
    autocreate_contact_portal: false
    # Whether or not to make portals of Signal groups in which joining via invite link does
    # not need to be approved by an administrator publicly joinable on Matrix.
    public_portals: false
    # Whether or not to use /sync to get read receipts and typing notifications
    # when double puppeting is enabled
    sync_with_custom_puppets: true
    # Whether or not to update the m.direct account data event when double puppeting is enabled.
    # Note that updating the m.direct event is not atomic (except with mautrix-asmux)
    # and is therefore prone to race conditions.
    sync_direct_chat_list: false
    # Allow using double puppeting from any server with a valid client .well-known file.
    double_puppet_allow_discovery: false
    # Servers to allow double puppeting from, even if double_puppet_allow_discovery is false.
    double_puppet_server_map:
        example.com: https://example.com
    login_shared_secret_map:
        example.com: foobar
    federate_rooms: true
    # End-to-bridge encryption support options.
    #
    # See https://docs.mau.fi/bridges/general/end-to-bridge-encryption.html for more info.
    encryption:
        # Allow encryption, work in group chat rooms with e2ee enabled
        allow: true
        # Default to encryption, force-enable encryption in all portals the bridge creates
        # This will cause the bridge bot to be in private chats for the encryption to work properly.
        default: false
        # Whether to use MSC2409/MSC3202 instead of /sync long polling for receiving encryption-related data.
        appservice: false
        # Require encryption, drop any unencrypted messages.
        require: false
        # Enable key sharing? If enabled, key requests for rooms where users are in will be fulfilled.
        # You must use a client that supports requesting keys from other users to use this feature.
        allow_key_sharing: false
        # What level of device verification should be required from users?
        #
        # Valid levels:
        #   unverified - Send keys to all device in the room.
        #   cross-signed-untrusted - Require valid cross-signing, but trust all cross-signing keys.
        #   cross-signed-tofu - Require valid cross-signing, trust cross-signing keys on first use (and reject changes).
        #   cross-signed-verified - Require valid cross-signing, plus a valid user signature from the bridge bot.
        #                           Note that creating user signatures from the bridge bot is not currently possible.
        #   verified - Require manual per-device verification
        #              (currently only possible by modifying the `trust` column in the `crypto_device` database table).
        verification_levels:
            # Minimum level for which the bridge should send keys to when bridging messages from Telegram to Matrix.
            receive: unverified
            # Minimum level that the bridge should accept for incoming Matrix messages.
            send: unverified
            # Minimum level that the bridge should require for accepting key requests.
            share: cross-signed-tofu
        # Options for Megolm room key rotation. These options allow you to
        # configure the m.room.encryption event content. See:
        # https://spec.matrix.org/v1.3/client-server-api/#mroomencryption for
        # more information about that event.
        rotation:
            # Enable custom Megolm room key rotation settings. Note that these
            # settings will only apply to rooms created after this option is
            # set.
            enable_custom: false
            # The maximum number of milliseconds a session should be used
            # before changing it. The Matrix spec recommends 604800000 (a week)
            # as the default.
            milliseconds: 604800000
            # The maximum number of messages that should be sent with a given a
            # session before changing it. The Matrix spec recommends 100 as the
            # default.
            messages: 100

    # Whether or not to explicitly set the avatar and room name for private
    # chat portal rooms. This will be implicitly enabled if encryption.default is true.
    private_chat_portal_meta: false
    # Whether or not the bridge should send a read receipt from the bridge bot when a message has
    # been sent to Signal. This let's you check manually whether the bridge is receiving your
    # messages.
    # Note that this is not related to Signal delivery receipts.
    delivery_receipts: false
    # Whether or not delivery errors should be reported as messages in the Matrix room.
    delivery_error_reports: false
    # Whether the bridge should send the message status as a custom com.beeper.message_send_status event.
    message_status_events: false
    # Set this to true to tell the bridge to re-send m.bridge events to all rooms on the next run.
    # This field will automatically be changed back to false after it,
    # except if the config file is not writable.
    resend_bridge_info: false
    # Interval at which to resync contacts (in seconds).
    periodic_sync: 0
    # Should leaving the room on Matrix make the user leave on Signal?
    bridge_matrix_leave: true

    # Provisioning API part of the web server for automated portal creation and fetching information.
    # Used by things like mautrix-manager (https://github.com/tulir/mautrix-manager).
    provisioning:
        # Whether or not the provisioning API should be enabled.
        enabled: false
        # The prefix to use in the provisioning API endpoints.
        prefix: /_matrix/provision
        # The shared secret to authorize users of the API.
        # Set to "generate" to generate and save a new token.
        shared_secret: UUUUUUUUUUUUU
        # Segment API key to enable analytics tracking for web server
        # endpoints. Set to null to disable.
        # Currently the only events are login start, QR code scan, and login
        # success/failure.
        segment_key:

    # The prefix for commands. Only required in non-management rooms.
    command_prefix: '!sg'

    # Messages sent upon joining a management room.
    # Markdown is supported. The defaults are listed below.
    management_room_text:
        # Sent when joining a room.
        welcome: Hello, I'm a Signal bridge bot.
        # Sent when joining a management room and the user is already logged in.
        welcome_connected: Use `help` for help.
        # Sent when joining a management room and the user is not logged in.
        welcome_unconnected: Use `help` for help or `link` to log in.
        # Optional extra text sent when joining a management room.
        additional_help: ''

    # Send each message separately (for readability in some clients)
    management_room_multiple_messages: false

    # Permissions for using the bridge.
    # Permitted values:
    #      relay - Allowed to be relayed through the bridge, no access to commands.
    #       user - Use the bridge with puppeting.
    #      admin - Use and administrate the bridge.
    # Permitted keys:
    #        * - All Matrix users
    #   domain - All users on that homeserver
    #     mxid - Specific user
    permissions:
        '*': relay
        MYDOMAIN.fr: user
        '@admin:MYDOMAIN.fr': admin
    relay:
        # Whether relay mode should be allowed. If allowed, `!signal set-relay` can be used to turn any
        # authenticated user into a relaybot for that chat.
        enabled: true
        # The formats to use when sending messages to Signal via a relay user.
        #
        # Available variables:
        #   $sender_displayname - The display name of the sender (e.g. Example User)
        #   $sender_username    - The username (Matrix ID localpart) of the sender (e.g. exampleuser)
        #   $sender_mxid        - The Matrix ID of the sender (e.g. @exampleuser:example.com)
        #   $message            - The message content
        message_formats:
            m.text: '$sender_displayname: $message'
            m.notice: '$sender_displayname: $message'
            m.emote: '* $sender_displayname $message'
            m.file: $sender_displayname sent a file
            m.image: $sender_displayname sent an image
            m.audio: $sender_displayname sent an audio file
            m.video: $sender_displayname sent a video
            m.location: $sender_displayname sent a location
        relaybot: '@relaybot:example.com'

    # Format for generating URLs from location messages for sending to Signal
    # Google Maps: 'https://www.google.com/maps/place/{lat},{long}'
    # OpenStreetMap: 'https://www.openstreetmap.org/?mlat={lat}&mlon={long}'
    location_format: https://www.openstreetmap.org/?mlat={lat}&mlon={long}

# Python logging configuration.
#
# See section 16.7.2 of the Python documentation for more info:
# https://docs.python.org/3.6/library/logging.config.html#configuration-dictionary-schema
logging:
    version: 1
    formatters:
        colored:
            (): mautrix_signal.util.ColorFormatter
            format: '[%(asctime)s] [%(levelname)s@%(name)s] %(message)s'
        normal:
            format: '[%(asctime)s] [%(levelname)s@%(name)s] %(message)s'
    handlers:
        file:
            class: logging.handlers.RotatingFileHandler
            formatter: normal
            filename: /var/log/mautrix_signal/mautrix_signal.log
            maxBytes: 10485760
            backupCount: 10
        console:
            class: logging.StreamHandler
            formatter: colored
    loggers:
        mau:
            level: INFO
        aiohttp:
            level: INFO
    root:
        level: INFO
        handlers: [file, console]

[Thatoo]

Could the command clear-cache-matrix help?

[kubo6472]

I tried re-logging in and it still didn't help

[melroy89]

The bot just seems to not response at all. Even the help command doesn't work. For some reason the bot just doesn't listen anymore, whatever the reason might be.

(Maybe I was too angry to the bot?)

[kubo6472]

The bot just seems to not response at all. Even the help command doesn't work. For some reason the bot just doesn't listen anymore, whatever the reason might be.

(Maybe I was too angry to the bot?)

Called abandonment. I did a whole docker-compose down && docker-compose pull && docker-compose up -d and it helped.

[melroy89]

Called abandonment. I did a whole docker-compose down && docker-compose pull && docker-compose up -d and it helped.

Still strange tho. It's not a Windows OS 😆. I bet the signal bot is crashing under the hood.. Or something else strange. Despite not showing errors in the logging.

[kubo6472]

Called abandonment. I did a whole docker-compose down && docker-compose pull && docker-compose up -d and it helped.

Still strange tho. It's not a Windows OS 😆. I bet the signal bot is crashing under the hood.. Or something else strange. Despite not showing errors in the logging.

Mine's working okay since. And it's been 3 days.

[olmari]

Either our server is hitting someting of this bug, or something else, but now our bot also basically doesn't work anymore.. Bot seems to be happy few moments at restart and then just fill up with these, without responding to anyone commanding or delivering messages or so...

Feb 05 22:54:29 morpheus.hacklab.fi python[936680]: [2023-02-05 22:54:29,647] [DEBUG@mau.as.api.bot] req #54 (/v3/rooms/<room>/state/m.room.join_rules/) completed in 6.6ms with status 200
Feb 05 22:54:29 morpheus.hacklab.fi python[936680]: [2023-02-05 22:54:29,647] [DEBUG@mau.user.@<user>:matrix.org] Sync complete
Feb 05 22:55:30 morpheus.hacklab.fi python[936680]: [2023-02-05 22:55:30,744] [INFO@mau.user.<user2>:hacklab.fi] New state since last TRANSIENT_DISCONNECT push, not transitioning to UNKNOWN_ERROR.
Feb 05 22:55:30 morpheus.hacklab.fi python[936680]: [2023-02-05 22:55:30,745] [INFO@mau.user.@<user2>:hacklab.fi] New state since last TRANSIENT_DISCONNECT push, not transitioning to UNKNOWN_ERROR.
Feb 05 22:55:30 morpheus.hacklab.fi python[936680]: [2023-02-05 22:55:30,759] [INFO@mau.user.@<user2>:hacklab.fi] New state since last CONNECTING push, not transitioning to UNKNOWN_ERROR.
Feb 05 22:55:30 morpheus.hacklab.fi python[936680]: [2023-02-05 22:55:30,766] [INFO@mau.user.@<user2>:hacklab.fi] New state since last CONNECTING push, not transitioning to UNKNOWN_ERROR.
Feb 05 22:55:34 morpheus.hacklab.fi python[936680]: [2023-02-05 22:55:34,410] [INFO@mau.user.@relaybot:hacklab.fi] New state since last TRANSIENT_DISCONNECT push, not transitioning to UNKNOWN_ERROR.
Feb 05 22:55:34 morpheus.hacklab.fi python[936680]: [2023-02-05 22:55:34,410] [INFO@mau.user.@relaybot:hacklab.fi] New state since last TRANSIENT_DISCONNECT push, not transitioning to UNKNOWN_ERROR.
Feb 05 22:55:34 morpheus.hacklab.fi python[936680]: [2023-02-05 22:55:34,425] [INFO@mau.user.@relaybot:hacklab.fi] New state since last CONNECTING push, not transitioning to UNKNOWN_ERROR.
Feb 05 22:55:34 morpheus.hacklab.fi python[936680]: [2023-02-05 22:55:34,427] [INFO@mau.user.@relaybot:hacklab.fi] New state since last CONNECTING push, not transitioning to UNKNOWN_ERROR.

[olmari]

Okay maybe false alarm, or at least resolvable, no idea what was possibly at "some state", but restarting also synapse and then signalbot and stuff seems to work again...

[crawford]

I'm seeing the same issue with my setup. signald is my primary device and I have been using the bridge to double puppet for a while without issue. Early this year, I noticed that certain 1:1 rooms were no longer receiving responses, though I could send messages. I believe I was running signald 0.23.0 and mautrix-signal 0.4.1 at the time (as packaged by NixOS), but I am now on signald 0.23.2.

In one of the affected rooms, I just tried running !signal help and got no response from the bridge. This works in the non-affected rooms though. I do see a stack trace from the bridge when I run the help command in one of the problematic rooms.

``` Feb 14 14:22:28 tenerife mautrix-signal[985]: [2023-02-14 14:22:28,084] [ERROR@mau.commands] Unhandled error while handling command help from @me:myhomeserver.redacted (ref: 1676378683) Feb 14 14:22:28 tenerife mautrix-signal[985]: Traceback (most recent call last): Feb 14 14:22:28 tenerife mautrix-signal[985]: File "/nix/store/ycn5c9pmd8sdrdsh0vkvq8ksfdynbpvl-python3.10-mautrix-0.18.8/lib/python3.10/site-packages/mautrix/appservice/api/intent.py", line 580, in ensure_joined Feb 14 14:22:28 tenerife mautrix-signal[985]: await self.join_room(room_id, max_retries=0) Feb 14 14:22:28 tenerife mautrix-signal[985]: File "/nix/store/ycn5c9pmd8sdrdsh0vkvq8ksfdynbpvl-python3.10-mautrix-0.18.8/lib/python3.10/site-packages/mautrix/appservice/api/intent.py", line 127, in wrapper Feb 14 14:22:28 tenerife mautrix-signal[985]: return await __method(*args, **kwargs) Feb 14 14:22:28 tenerife mautrix-signal[985]: File "/nix/store/ycn5c9pmd8sdrdsh0vkvq8ksfdynbpvl-python3.10-mautrix-0.18.8/lib/python3.10/site-packages/mautrix/client/store_updater.py", line 62, in join_room Feb 14 14:22:28 tenerife mautrix-signal[985]: room_id = await super().join_room( Feb 14 14:22:28 tenerife mautrix-signal[985]: File "/nix/store/ycn5c9pmd8sdrdsh0vkvq8ksfdynbpvl-python3.10-mautrix-0.18.8/lib/python3.10/site-packages/mautrix/client/api/rooms.py", line 335, in join_room Feb 14 14:22:28 tenerife mautrix-signal[985]: content = await self.api.request( Feb 14 14:22:28 tenerife mautrix-signal[985]: File "/nix/store/ycn5c9pmd8sdrdsh0vkvq8ksfdynbpvl-python3.10-mautrix-0.18.8/lib/python3.10/site-packages/mautrix/api.py", line 401, in request Feb 14 14:22:28 tenerife mautrix-signal[985]: resp_data, resp = await self._send( Feb 14 14:22:28 tenerife mautrix-signal[985]: File "/nix/store/ycn5c9pmd8sdrdsh0vkvq8ksfdynbpvl-python3.10-mautrix-0.18.8/lib/python3.10/site-packages/mautrix/api.py", line 256, in _send Feb 14 14:22:28 tenerife mautrix-signal[985]: raise make_request_error( Feb 14 14:22:28 tenerife mautrix-signal[985]: mautrix.errors.request.MForbidden: You are not invited to this room. Feb 14 14:22:28 tenerife mautrix-signal[985]: During handling of the above exception, another exception occurred: Feb 14 14:22:28 tenerife mautrix-signal[985]: Traceback (most recent call last): Feb 14 14:22:28 tenerife mautrix-signal[985]: File "/nix/store/ycn5c9pmd8sdrdsh0vkvq8ksfdynbpvl-python3.10-mautrix-0.18.8/lib/python3.10/site-packages/mautrix/appservice/api/intent.py", line 580, in ensure_joined Feb 14 14:22:28 tenerife mautrix-signal[985]: await self.join_room(room_id, max_retries=0) Feb 14 14:22:28 tenerife mautrix-signal[985]: File "/nix/store/ycn5c9pmd8sdrdsh0vkvq8ksfdynbpvl-python3.10-mautrix-0.18.8/lib/python3.10/site-packages/mautrix/appservice/api/intent.py", line 127, in wrapper Feb 14 14:22:28 tenerife mautrix-signal[985]: return await __method(*args, **kwargs) Feb 14 14:22:28 tenerife mautrix-signal[985]: File "/nix/store/ycn5c9pmd8sdrdsh0vkvq8ksfdynbpvl-python3.10-mautrix-0.18.8/lib/python3.10/site-packages/mautrix/client/store_updater.py", line 62, in join_room Feb 14 14:22:28 tenerife mautrix-signal[985]: room_id = await super().join_room( Feb 14 14:22:28 tenerife mautrix-signal[985]: File "/nix/store/ycn5c9pmd8sdrdsh0vkvq8ksfdynbpvl-python3.10-mautrix-0.18.8/lib/python3.10/site-packages/mautrix/client/api/rooms.py", line 335, in join_room Feb 14 14:22:28 tenerife mautrix-signal[985]: content = await self.api.request( Feb 14 14:22:28 tenerife mautrix-signal[985]: File "/nix/store/ycn5c9pmd8sdrdsh0vkvq8ksfdynbpvl-python3.10-mautrix-0.18.8/lib/python3.10/site-packages/mautrix/api.py", line 401, in request Feb 14 14:22:28 tenerife mautrix-signal[985]: resp_data, resp = await self._send( Feb 14 14:22:28 tenerife mautrix-signal[985]: File "/nix/store/ycn5c9pmd8sdrdsh0vkvq8ksfdynbpvl-python3.10-mautrix-0.18.8/lib/python3.10/site-packages/mautrix/api.py", line 256, in _send Feb 14 14:22:28 tenerife mautrix-signal[985]: raise make_request_error( Feb 14 14:22:28 tenerife mautrix-signal[985]: mautrix.errors.request.MForbidden: You are not invited to this room. Feb 14 14:22:28 tenerife mautrix-signal[985]: The above exception was the direct cause of the following exception: Feb 14 14:22:28 tenerife mautrix-signal[985]: Traceback (most recent call last): Feb 14 14:22:28 tenerife mautrix-signal[985]: File "/nix/store/ycn5c9pmd8sdrdsh0vkvq8ksfdynbpvl-python3.10-mautrix-0.18.8/lib/python3.10/site-packages/mautrix/bridge/commands/handler.py", line 491, in handle Feb 14 14:22:28 tenerife mautrix-signal[985]: await self._run_handler(handler, evt) Feb 14 14:22:28 tenerife mautrix-signal[985]: File "/nix/store/ycn5c9pmd8sdrdsh0vkvq8ksfdynbpvl-python3.10-mautrix-0.18.8/lib/python3.10/site-packages/mautrix/bridge/commands/handler.py", line 340, in __call__ Feb 14 14:22:28 tenerife mautrix-signal[985]: return await self._handler(evt) Feb 14 14:22:28 tenerife mautrix-signal[985]: File "/nix/store/ycn5c9pmd8sdrdsh0vkvq8ksfdynbpvl-python3.10-mautrix-0.18.8/lib/python3.10/site-packages/mautrix/bridge/commands/meta.py", line 89, in help_cmd Feb 14 14:22:28 tenerife mautrix-signal[985]: return await evt.reply(_get_management_status(evt) + "\n" + await _get_help_text(evt)) Feb 14 14:22:28 tenerife mautrix-signal[985]: File "/nix/store/ycn5c9pmd8sdrdsh0vkvq8ksfdynbpvl-python3.10-mautrix-0.18.8/lib/python3.10/site-packages/mautrix/client/api/events.py", line 525, in send_text Feb 14 14:22:28 tenerife mautrix-signal[985]: return await self.send_message(room_id, content, **kwargs) Feb 14 14:22:28 tenerife mautrix-signal[985]: File "/nix/store/ycn5c9pmd8sdrdsh0vkvq8ksfdynbpvl-python3.10-mautrix-0.18.8/lib/python3.10/site-packages/mautrix/appservice/api/intent.py", line 140, in wrapper Feb 14 14:22:28 tenerife mautrix-signal[985]: await __self.ensure_joined(room_id) Feb 14 14:22:28 tenerife mautrix-signal[985]: File "/nix/store/ycn5c9pmd8sdrdsh0vkvq8ksfdynbpvl-python3.10-mautrix-0.18.8/lib/python3.10/site-packages/mautrix/appservice/api/intent.py", line 586, in ensure_joined Feb 14 14:22:28 tenerife mautrix-signal[985]: await bot.invite_user(room_id, self.mxid) Feb 14 14:22:28 tenerife mautrix-signal[985]: File "/nix/store/ycn5c9pmd8sdrdsh0vkvq8ksfdynbpvl-python3.10-mautrix-0.18.8/lib/python3.10/site-packages/mautrix/appservice/api/intent.py", line 140, in wrapper Feb 14 14:22:28 tenerife mautrix-signal[985]: await __self.ensure_joined(room_id) Feb 14 14:22:28 tenerife mautrix-signal[985]: File "/nix/store/ycn5c9pmd8sdrdsh0vkvq8ksfdynbpvl-python3.10-mautrix-0.18.8/lib/python3.10/site-packages/mautrix/appservice/api/intent.py", line 584, in ensure_joined Feb 14 14:22:28 tenerife mautrix-signal[985]: raise IntentError(f"Failed to join room {room_id} as {self.mxid}") from e Feb 14 14:22:28 tenerife mautrix-signal[985]: mautrix.errors.base.IntentError: Failed to join room !roomid:myhomeserver.redacted as @signalbot:myhomeserver.redacted ```

[EderChri]

I am having the same issues, the restarting suggested by @kubo6472 did not help though

[crawford]

While I was discussing this a bit more last night with some folks, I realized that in the affected rooms, the ghost/puppet ID was of the form @signal_phone_<phone number>, while the ghost/puppet in the unaffected rooms was @signal_<UUID> (I'm using unencrypted rooms with my bridge). This seems to suggest that something went wrong during an update.

[kubo6472]

This happens only in a single chat. Those are not attachments, but rather normal messages. Any idea?

[philippludwig]

I have setup the signal bridge just now, and while I can send messages to my signal contacts, I cannot receive any from them. The logs don’t show anything useful, sadly.