SAYFROM not appearing in channel message

[abma]

this is whats send from the appservice:

Sep 18 11:01:25 spring1 sappservice[12074]: [2020-09-18 11:01:25,242] [DEBUG@asyncspring.protocol] SENT: b'SAYFROM sy springrts.com abma Ping'

but with springlobby the message isn't shown: did i miss something?

there are a lot of returns without error messages in https://github.com/spring/uberserver/blob/976e1131fd1314dbd30b2355db2ad491117ddd50/protocol/Protocol.py#L1415 which very likely hides the error?!

[TurBoss]

I think is something with your account

when I did setup the matrix server i created 2 main accounts but latter the auth provider against uberserberdb was added

so if you login with @abma:springrts.com you are loging with the matrix admin account but iy you just type your lobby account user @id_123456:springrts.com is begin used

what the appservice does is replcae the localpart "@id_12345" with your lobby nick name

but uberserver is not happy having 2 of the same "localpart" aka "external_id" from the same location

having this I don't use my admin accouns but lobby one

so it must be just you the only affected :-(

[abma]

oh, i didn't know this, so my fault. ill try with the @id_... account soon, thanks!

[TurBoss]

the appservice sets "external_id" the matrix "Display Name" which one can change and matrix supports having 2 display names from the same server

so the external_id for @abma:springrts.com and @id_12345:springrts.com ends begin the same

duno how to fix this issue

iirc external_id is index_key or something

:/

[silentwings]

but uberserver is not happy having 2 of the same "localpart" aka "external_id" from the same location

External_id has to be unique - because something has to uniquely and permanently identify an external client, on both sides of the bridge. Name/location are not sufficient, because external clients can rename themselves. It is the responsibility of the bridge to choose a perma-unique external_id for each of its bridged clients (per bridged location). External services typically have such things anyway e.g. there is a discord_id.

External_id could allow more chars, if it would be helpful.

there are a lot of returns without error messages in def in_SAYFROM(self, client, chan, location, external_id, msg) which very likely hides the error?!

In fact there are only two silent failure cases:

• If a bridge tries to send a message for a bridged client that is owned by a different bridge.
• If a bridge tries to send a message for a bridged client that does not exist at all.

Bridges should keep track of which clients they have bridged in successfully (and of any failed attempts). They can do so via the error messages returned in JSON form by https://github.com/spring/uberserver/blob/976e1131fd1314dbd30b2355db2ad491117ddd50/protocol/Protocol.py#L1289 which does not have any silent failure cases. So, there are no circumstances under which a bridge should trigger either of the two silent failure cases above; if it happens then the bridge has either malfunctioned or (most likely) already ignored an error message sent in response to BRIDGECLIENTFROM.

So, I don't think there is any error in uberserver here?