You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Crash: canonical_alias_has_value? - has no value.. 馃槈 聽#37
irb(main):038> tchncs.join_room room
/var/lib/gems/3.3.0/gems/matrix_sdk-2.8.0/lib/matrix_sdk/room.rb:116:in `to_s': undefined method `canonical_alias_has_value?' for an instance of MatrixSdk::Room (NoMethodError)
prefix = canonical_alias if canonical_alias_has_value?
^^^^^^^^^^^^^^^^^^^^^^^^^^
Did you mean? canonical_alias
from /var/lib/gems/3.3.0/gems/matrix_sdk-2.8.0/lib/matrix_sdk/protocols/cs.rb:496:in `join_room'
from /var/lib/gems/3.3.0/gems/matrix_sdk-2.8.0/lib/matrix_sdk/client.rb:397:in `join_room'
from (irb):38:in `<main>'
from <internal:kernel>:187:in `loop'
from /var/lib/gems/3.3.0/gems/irb-1.15.2/exe/irb:9:in `<top (required)>'
from /usr/local/bin/irb:25:in `load'
from /usr/local/bin/irb:25:in `<main>'
Right, the main issue here seems to be that you are giving a MatrixSdk::Room instance to the Client#join_room method, but it should definitely handle that case more gracefully.
Using client.join_room room.id should work in the meantime.
Ah, thanks! I am still groping my way trying to find out how to use the API. It felt right, giving a room as the argument to .join_room.
And good to see the project is still alive! All the files had dates of several years ago, so I was afraid it麓d be dead.
Thanks for writing this gem!
I am trying to write a small account migration script, and so far have this:
require 'matrix_sdk'
old = MatrixSdk::Client.new 'https://server.old'
old.login 'oldname', 'OldPass'
new = MatrixSdk::Client.new 'https://server.new'
newName = '@newname:server.new'
tchncs.login 'newname', 'NewPass'
old.reload_rooms!
newID = old.get_user newName # MUST be done on old; on new this gives another value.
old.rooms.each {|room| room.invite_user newName unless room.all_members.include? newID ; sleep 10; new.join_room room, server_name: ['server.old']; putc ?.}
Any other bits I got wrong?
It seems the "sleep 10" may need to become a much higher value, to avoid hitting rate limits.
Definitely agree that it feels reasonable to use Room/User arguments for methods on a Client instance, just not been something that's come up in my own use or testing.
This gem still is quite alive if a bit - read glacially - slow on development, we're running a bunch of integrations that depend on it at work, but unfortunately it's still working just fine as it is so I haven't really had the time to dedicate to it.
When it comes to the migration script, it certainly looks reasonable. If you're okay with actually bumping into the rate limits, the SDK should automatically respect them and wait before continuing/retrying. (But this is built against Synapse, so other servers that use the Retry-After header won't be respected properly at the moment)
Well, assuming I won't be punished with extra restrictions when bumping into them, that would be the simplest way.
Great to hear that you check the Retry-After - I assume that takes the load off me.
One other issue I often run into is when logging in. It happens, but upon retrying all works well.
biep@Puk-1:~$ irb
irb(main):001> require 'matrix_sdk'
=> true
irb(main):002> server = MatrixSdk::Client.new 'https://server.old'
=> #<MatrixSdk::Client:0x00007c90d2ce2c70 ...>
irb(main):003> server.login 'user', 'Password'
/var/lib/gems/3.3.0/gems/matrix_sdk-2.8.0/lib/matrix_sdk/room.rb:985:in `sort': comparison of String with nil failed (ArgumentError)
from /var/lib/gems/3.3.0/gems/matrix_sdk-2.8.0/lib/matrix_sdk/room.rb:985:in `handle_room_canonical_alias'
from /var/lib/gems/3.3.0/gems/matrix_sdk-2.8.0/lib/matrix_sdk/room.rb:1032:in `put_state_event'
from /var/lib/gems/3.3.0/gems/matrix_sdk-2.8.0/lib/matrix_sdk/client.rb:618:in `handle_state'
from /var/lib/gems/3.3.0/gems/matrix_sdk-2.8.0/lib/matrix_sdk/client.rb:667:in `block (2 levels) in handle_sync_response'
from /var/lib/gems/3.3.0/gems/matrix_sdk-2.8.0/lib/matrix_sdk/client.rb:661:in `each'
from /var/lib/gems/3.3.0/gems/matrix_sdk-2.8.0/lib/matrix_sdk/client.rb:661:in `block in handle_sync_response'
from /var/lib/gems/3.3.0/gems/matrix_sdk-2.8.0/lib/matrix_sdk/client.rb:644:in `each'
from /var/lib/gems/3.3.0/gems/matrix_sdk-2.8.0/lib/matrix_sdk/client.rb:644:in `handle_sync_response'
from /var/lib/gems/3.3.0/gems/matrix_sdk-2.8.0/lib/matrix_sdk/client.rb:551:in `sync'
from /var/lib/gems/3.3.0/gems/matrix_sdk-2.8.0/lib/matrix_sdk/client.rb:293:in `login'
from (irb):3:in `<main>'
from <internal:kernel>:187:in `loop'
from /var/lib/gems/3.3.0/gems/irb-1.15.2/exe/irb:9:in `<top (required)>'
from /usr/local/bin/irb:25:in `load'
from /usr/local/bin/irb:25:in `<main>'
irb(main):004> server.login 'user', 'Password'
=> true
irb(main):005>
When it comes to the migration script, it certainly looks reasonable. If you're okay with actually bumping into the rate limits, the SDK should automatically respect them and wait before continuing/retrying. (But this is built against Synapse, so other servers that use the Retry-After header won't be respected properly at the moment)
I fear I should not have relied on this..
irb(main):009> old.rooms.each {|room| room.invite_user '@user:server.new' unless room.all_members.include? btc ; sleep 10; new.join_room room.id, server_name: ['server.old']; putc ?.}
................/var/lib/gems/3.3.0/gems/matrix_sdk-2.8.0/lib/matrix_sdk/api.rb:348:in `block in request': Server is banned from room (MatrixSdk::MatrixForbiddenError)
from <internal:kernel>:187:in `loop'
from /var/lib/gems/3.3.0/gems/matrix_sdk-2.8.0/lib/matrix_sdk/api.rb:294:in `request'
from /var/lib/gems/3.3.0/gems/matrix_sdk-2.8.0/lib/matrix_sdk/protocols/cs.rb:1198:in `invite_user'
from /var/lib/gems/3.3.0/gems/matrix_sdk-2.8.0/lib/matrix_sdk/room.rb:530:in `invite_user'
from (irb):9:in `block in <top (required)>'
from (irb):9:in `each'
from (irb):9:in `<main>'
from <internal:kernel>:187:in `loop'
from /var/lib/gems/3.3.0/gems/irb-1.15.2/exe/irb:9:in `<top (required)>'
from /usr/local/bin/irb:25:in `load'
from /usr/local/bin/irb:25:in `<main>'
It wasn't as bad as I feared - just a single room that had banned the server (or not even that, as both accounts could enter it on their own. So a bit of exception handling was all that was needed.
irb(main):013> account=MatrixSdk::Client.new server
=> #<MatrixSdk::Client:0x00007adee3787e58 ...>
irb(main):014> account.login name, password
/var/lib/gems/3.3.0/gems/matrix_sdk-2.8.0/lib/matrix_sdk/api.rb:370:in `construct_request': undefined method `request_uri' for an instance of URI::Generic (NoMethodError)
request = Net::HTTP.const_get(method.to_s.capitalize.to_sym).new url.request_uri
^^^^^^^^^^^^
from /var/lib/gems/3.3.0/gems/matrix_sdk-2.8.0/lib/matrix_sdk/api.rb:299:in `block in request'
from <internal:kernel>:187:in `loop'
from /var/lib/gems/3.3.0/gems/matrix_sdk-2.8.0/lib/matrix_sdk/api.rb:294:in `request'
from /var/lib/gems/3.3.0/gems/matrix_sdk-2.8.0/lib/matrix_sdk/protocols/cs.rb:205:in `login'
from /var/lib/gems/3.3.0/gems/matrix_sdk-2.8.0/lib/matrix_sdk/client.rb:288:in `login'
from (irb):14:in `<main>'
from <internal:kernel>:187:in `loop'
from /var/lib/gems/3.3.0/gems/irb-1.15.2/exe/irb:9:in `<top (required)>'
from /usr/local/bin/irb:25:in `load'
from /usr/local/bin/irb:25:in `<main>'
This error repeats - redoing the login gives the same error again.
Not sure you want to catch this one and handle it gracefully..
/var/lib/gems/3.3.0/gems/net-http-0.6.0/lib/net/http.rb:1665:in `initialize': Failed to open TCP connection to synod.im:443 (execution expired) (Net::OpenTimeout)
from /var/lib/gems/3.3.0/gems/net-http-0.6.0/lib/net/http.rb:1665:in `open'
from /var/lib/gems/3.3.0/gems/net-http-0.6.0/lib/net/http.rb:1665:in `block in connect'
from /var/lib/gems/3.3.0/gems/timeout-0.4.3/lib/timeout.rb:185:in `block in timeout'
from /var/lib/gems/3.3.0/gems/timeout-0.4.3/lib/timeout.rb:192:in `timeout'
from /var/lib/gems/3.3.0/gems/net-http-0.6.0/lib/net/http.rb:1663:in `connect'
from /var/lib/gems/3.3.0/gems/net-http-0.6.0/lib/net/http.rb:1642:in `do_start'
from /var/lib/gems/3.3.0/gems/net-http-0.6.0/lib/net/http.rb:1637:in `start'
from /var/lib/gems/3.3.0/gems/matrix_sdk-2.8.0/lib/matrix_sdk/api.rb:441:in `http'
from /var/lib/gems/3.3.0/gems/matrix_sdk-2.8.0/lib/matrix_sdk/api.rb:303:in `block in request'
from <internal:kernel>:187:in `loop'
from /var/lib/gems/3.3.0/gems/matrix_sdk-2.8.0/lib/matrix_sdk/api.rb:294:in `request'
from /var/lib/gems/3.3.0/gems/matrix_sdk-2.8.0/lib/matrix_sdk/protocols/cs.rb:1198:in `invite_user'
from /var/lib/gems/3.3.0/gems/matrix_sdk-2.8.0/lib/matrix_sdk/room.rb:530:in `invite_user'
from /home/biep/.local/bin/migreer:36:in `block in <main>'
from /home/biep/.local/bin/migreer:32:in `each'
from /home/biep/.local/bin/migreer:32:in `<main>'
This happened after my script had been running for several days, with interruptions whenever I put my computer to sleep, and upon waking had to re-establish the WiFi connection.
Activity
[-]canonical_alias_has_value[/-][+]Crash: `canonical_alias_has_value?` - has no value.. 馃槈 [/+]ananace commentedon Apr 22, 2025
Right, the main issue here seems to be that you are giving a
MatrixSdk::Roominstance to theClient#join_roommethod, but it should definitely handle that case more gracefully.Using
client.join_room room.idshould work in the meantime.Biep commentedon Apr 22, 2025
Ah, thanks! I am still groping my way trying to find out how to use the API. It felt right, giving a room as the argument to
.join_room.And good to see the project is still alive! All the files had dates of several years ago, so I was afraid it麓d be dead.
Thanks for writing this gem!
Biep commentedon Apr 22, 2025
I am trying to write a small account migration script, and so far have this:
Any other bits I got wrong?
It seems the "
sleep 10" may need to become a much higher value, to avoid hitting rate limits.Sadly, the semi-official migration tool stopped working.
ananace commentedon Apr 22, 2025
Definitely agree that it feels reasonable to use
Room/Userarguments for methods on aClientinstance, just not been something that's come up in my own use or testing.This gem still is quite alive if a bit - read glacially - slow on development, we're running a bunch of integrations that depend on it at work, but unfortunately it's still working just fine as it is so I haven't really had the time to dedicate to it.
When it comes to the migration script, it certainly looks reasonable. If you're okay with actually bumping into the rate limits, the SDK should automatically respect them and wait before continuing/retrying. (But this is built against Synapse, so other servers that use the Retry-After header won't be respected properly at the moment)
Biep commentedon Apr 24, 2025
Well, assuming I won't be punished with extra restrictions when bumping into them, that would be the simplest way.
Great to hear that you check the
Retry-After- I assume that takes the load off me.One other issue I often run into is when logging in. It happens, but upon retrying all works well.
Biep commentedon Apr 24, 2025
I fear I should not have relied on this..
Biep commentedon Apr 26, 2025
It wasn't as bad as I feared - just a single room that had banned the server (or not even that, as both accounts could enter it on their own. So a bit of exception handling was all that was needed.
Biep commentedon Apr 26, 2025
This, too I solved with exception handling and retry, as I know it only fails the first time. It is still a genuine bug, though.
I login on two servers, and only the first time on the first server goes wrong. Feels like some initialisation error.
Biep commentedon Apr 29, 2025
A new error:
This error repeats - redoing the login gives the same error again.
Biep commentedon Apr 29, 2025
Not sure you want to catch this one and handle it gracefully..
This happened after my script had been running for several days, with interruptions whenever I put my computer to sleep, and upon waking had to re-establish the WiFi connection.