This fixes panics that happen because the handlers assume the user is logged
in when the command is executed.
Example of a panic that happened:
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x928d7c]
goroutine 127 [running]:
main.(*CommandHandler).CommandList(0xc0001783c0, 0xc00016bef8)
/build/commands.go:186 +0x6c
main.(*CommandHandler).Handle(0xc0001783c0, 0xc000455920, 0x1b,
0xc0002480c0, 0xc000250470, 0x4)
/build/commands.go:89 +0x1f3
main.(*MatrixHandler).HandleMessage(0xc000176db0, 0xc0001ae6c0)
/build/matrix.go:161 +0x203
created by maunium.net/go/mautrix-appservice.(*EventProcessor).Start
After user succesfully sets up bridge, bot will tell what to do next. This info had still old command so I updated message to reflect new 'sync' directive.
Because the Bridge Bot doesn't participate in the rooms it can't send any
messages to this room. Hence, we should send all replies to the management
room.
Having an import of all contacts on each startup and after login is very
annoying, if you have a big list of contacts. If you choose to not join a
room with all contacts, you get the invitation over and over on each
restart of the service. Better is to have a command for the management
room to explicitly start the import.
In the log some message show up with `/_matrix/client/r0/createRoom
code=403 wrapped=M_FORBIDDEN: Application service has not registered this
user`. This is caused by the handling of text messages coming from unknown
users:
mautrix-whatsapp/vendor/github.com/Rhymen/go-whatsapp/handler.go:106
mautrix-whatsapp/user.go:250
mautrix-whatsapp/portal.go:551
Hence, before creating a Matrix room, we must ensure the user for this
room exists.
When a request for GetProfilePicThumb fails, WhatsApp sends an JSON object
containing a status field: `{"status":404}`. In my tests, it did send the
codes 401 and 404 which might correspond to the HTTP status codes. At
least, we don't have data to update the avatar and should stop doing so.
When a request for GroupMetadata fails, WhatsApp sends an JSON object
containing a status field: `{"status":500}`. In my tests, it sends the
codes 401, 404 and 500 which might have the meaning of the HTTP status
codes. At least, we don't have data to update the portal and should stop
doing anything.
