Crash: `canonical_alias_has_value?` - has no value.. 😉

[Biep]

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>'

[ananace]

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.

[Biep]

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]

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.

Sadly, the semi-official migration tool stopped working.

[ananace]

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)

[Biep]

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> 

[Biep]

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>'

[Biep]

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]

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]

A new error:

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.

[Biep]

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.