main fails due to NoMethodError when calling competition.country.iso2

[lgarron]

Describe the bug

main fails due to NoMethodError when calling competition.country.iso2

To Reproduce

1. Launch a codespace at https://github.com/thewca/worldcubeassociation.org/codespaces
2. Run commands from the quickstart guide (https://docs.worldcubeassociation.org/contributing/quickstart.html):

# In one shell
docker-compose up

# In another shell once the first shell is showing stable output
docker exec -it rails bash -c "bin/rake db:reset"

3. Visit the site on port 3000 (at http://127.0.0.1:3000/competitions if you forward port 3000)

Expected behavior

The site is served.

Screenshots

Desktop (please complete the following information):

• OS: macOS 15.2
• Browser: Chrome 131.0.6778.265
• Version: eb7f6943db242ec1c7a309f192d3baef88b9ab94 (tip-of-tree on main)

If I comment out the failing line, this reveals that it's caused by a multi-location comp:

This is similar to #1853 , but it's reproduced for me on main (and a few other commits) in multiple codespaces. So it's quite reproducible.

[FinnIckler]

do you mean main? we haven't had master in like 2 years

[lgarron]

do you mean main? we haven't had master in like 2 years

uhh, yes. Sorry, I was working with something with master a bit ago (which is very unusual for me, so it seems that stuck in my head too long!).

But eb7f694 is definitely tip-of-tree for main.

[FinnIckler]

What happens if you load the dev export instead?
docker exec -it rails bash -c "bin/rails db:load:development"
it takes like 20 minutes

[lgarron]

What happens if you load the dev export instead? docker exec -it rails bash -c "bin/rails db:load:development" it takes like 20 minutes

Given that docker exec -it rails bash -c "bin/rake db:reset" takes very close to 10 minutes, I'm afraid to try.

But I can try this in a high-spec codespace some time later.
(I don't want to run it unsupervised, since I have to pay personally by usage.)

[lgarron]

What happens if you load the dev export instead? docker exec -it rails bash -c "bin/rails db:load:development" it takes like 20 minutes

Given that docker exec -it rails bash -c "bin/rake db:reset" takes very close to 10 minutes, I'm afraid to try.

But I can try this in a high-spec codespace some time later. (I don't want to run it unsupervised, since I have to pay personally by usage.)

Okay, I ended up trying this in an 8-core codespace (32GB RAM). It got this far and then didn't print anything else for over an hour:

╭─── /workspaces/worldcubeassociation.org ────────────────────────────────────────────────────────
├─  main ↓1 | ✔ 
├─ codespace@codespaces-71eae6
│ docker exec -it rails bash -c "bin/rails db:load:development"
┴
warning: parser/current is loading parser/ruby33, which recognizes 3.3.6-compliant syntax, but you are running 3.3.5.
Please see https://github.com/whitequark/parser#compatibility-with-ruby-mri.
Running via Spring preloader in process 285
Downloading https://assets.worldcubeassociation.org/export/developer/wca-developer-database-dump.zip...  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  496M  100  496M    0     0  19.3M      0  0:00:25  0:00:25 --:--:-- 20.4M
done in 25.67s
Unzipping dump.zip...Archive:  ./dump.zip
  inflating: wca-developer-database-dump.sql  
done in 17.95s
Clobbering contents of 'wca_development' with ./dump.zip...Dropped database 'wca_development'
Created database 'wca_development'

Here's the stack trace from aborting with Ctrl-C:

^Crake aborted!
Interrupt: Interrupt
/app/lib/database_dumper.rb:1248:in `system'
/app/lib/database_dumper.rb:1248:in `system_pipefail!'
/app/lib/database_dumper.rb:1228:in `mysql'
/app/lib/tasks/db.rake:100:in `block (6 levels) in <top (required)>'
/usr/local/bundle/3.3.5/ruby/3.3.0/gems/benchmark-0.4.0/lib/benchmark.rb:323:in `realtime'
/app/lib/log_task.rb:6:in `log_task'
/app/lib/tasks/db.rake:77:in `block (5 levels) in <top (required)>'
/app/lib/tasks/db.rake:60:in `block (4 levels) in <top (required)>'
/app/lib/tasks/db.rake:59:in `block (3 levels) in <top (required)>'
<internal:/usr/local/lib/ruby/site_ruby/3.3.0/rubygems/core_ext/kernel_require.rb>:136:in `require'
<internal:/usr/local/lib/ruby/site_ruby/3.3.0/rubygems/core_ext/kernel_require.rb>:136:in `require'
-e:1:in `<main>'
Tasks: TOP => db:load:development
(See full trace by running task with --trace)
⏎                                                        
┬
├─ ❌ [1] command status
╰─── ⏱️ 3879.473s ───────────────────────────────────────

[FinnIckler]

do you have control over how much ram is allocated for docker? To speed it up we configured the mycnf

[client]
default-character-set          = utf8mb4

[mysql]
default-character-set          = utf8mb4

[mysqld]
collation-server = utf8mb4_unicode_ci
character-set-server = utf8mb4
log-error-verbosity=1
max_allowed_packet = 512M
innodb_buffer_pool_size = 4G
innodb_log_buffer_size = 256M
innodb_log_file_size = 1G
innodb_write_io_threads = 16
innodb_doublewrite = 0

to need at least 4GB of RAM able to be allocated to the Mysql process

[lgarron]

do you have control over how much ram is allocated for docker? To speed it up we configured the mycnf

I'm not sure. I tried looking it up, and I don't see an obvious flag I can pass to docker-compose.

To be very blunt, this whole situations sets off my "trying to debug this will lead me to a dozen hours of yak shaving" red flags, so I'd rather put this off in favor of something like getting things working in codespaces without Docker (which is something Gregor and I have started talking about). If that leads to codespace prebuilds, that would make it much, much easier for someone like me to make contributions to the codebase.