Rebuilding always fails when the daily limit is exhausted. I think it would be good to fix this because I lost 2 days and set up a server twice until I found out what caused this problem. Maybe I’m not very smart 
I think you should skip this process and continue to recreate when the daily limit runs out.
Yes. It’s a huge problem that an error with MAXMIND causes a rebuild to fail. I guess on their hosting they must somehow share the db across instances.
I didn’t know about a daily limit, but that certainly explains the spurious errors that I’ve seen. The only solution is to disable maxmind to do a rebuild.
I’ve looked at the code a couple of times to try to figure out a fix but haven’t yet done it. It must be a 1-3 line fix.
Since you’ve finally identified that the issue is their rate limiting, I’m changing this to a 
I disable MAXMIND and recompile, and it works. However, I wanted to report this because I thought it might happen to others. Thank you for your interest, good luck.
Here is a trivial, but likely effective fix for this problem:
Since I don’t know exactly how to cause the problem it’s not easy to test the code, but it should work.
I’ll do some work tonight, and if I see any information about the error, I’ll update the topic. Thank you for your time, I think it will be useful.
Has any study been done on this subject? because I just did it and it still doesn’t compile when MAXMIND is on and I had to close it to compile. Might help, I see zlip error as well.
NOT:
I think I entered the license key incorrectly in app.yml. I fixed this and compile again. However, even if it is faulty or the limit is exhausted, it must continue compiling without giving any errors.
For that error, do you have the DISCOURSE_MAXMIND_ACCOUNT_ID added to your app.yml as well?
Can you share the whole logs?
If I encounter this error again, I will share the error logs, but it is the same as in the link you gave.
On the other hand, when the key is incorrect, compilation gives an error. So, it would be a good idea for this feature to continue and give a warning if there is a wrong key or id.
Well, it seems not to work with what I’m fairly certain is a valid maxmind key. I guess since I have several sites on the same IP all requesting the database I’m hitting rate limits?
...
Checking 'Guest Gate Theme Component' for 'default'... up to date
Checking '* Official: discourse-search-banner' for 'default'... up to date
Checking '* Official: Header submenus' for 'default'... up to date
Checking '* Auto linkify words (official)' for 'default'... up to date
Checking '* Official: New PM Dropdown Button (KED)' for 'default'... up to date
Checking 'Sidebar Theme Toggle' for 'default'... up to date
Downloading MaxMindDB...
FAILED
--------------------
Plugin name is 'DiscourseAddToSummary', but plugin directory is named 'discourse-add-to-summary'
Purging temp files
Bundling assets
I, [2024-07-03T15:34:03.558862 #1728] INFO -- : Writing /var/www/discourse/public/assets/break_string-cc617154cd957804f2f6a1f3bc68258c9cdca3d4b9a322
bf777d145fed04790e.js
I, [2024-07-03T15:34:03.565737 #1728] INFO -- : Writing /var/www/discourse/public/assets/service-worker-1c2f90c0e9ecfcf748d58ed6c37a510b3cd246299fcf
a5917a060293f1affb92.js
I, [2024-07-03T15:34:03.568027 #1728] INFO -- : Writing /var/www/discourse/public/assets/locales/i18n-3b40e842fd72b9bcc74ea83e094c823cd9ca535e4ecc5e
78722e6f99d3656137.js
I, [2024-07-03T15:34:03.569522 #1728] INFO -- : Writing /var/www/discourse/public/assets/scripts/discourse-test-listen-boot-9b14a0fc65c689577e6a428d
cfd680205516fe211700a71c7adb5cbcf4df2cc5.js
I, [2024-07-03T15:34:04.079476 #1728] INFO -- : Writing /var/www/discourse/public/assets/locales/ar-583c921ae692b1e7c988997efcba99e6b41b62572682166e
2c62bae0caeaab2b.js
I, [2024-07-03T15:34:04.373049 #1728] INFO -- : Writing /var/www/discourse/public/assets/locales/be-ee1a0dd42713e1ca29dbacea5dcde76c51a441cb634c5d61
7ba4b20bb7ef5b05.js
rake aborted!
Zlib::BufError: buffer error (Zlib::BufError)
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/cache/file_store.rb:100:in `<<'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/cache/file_store.rb:100:in `set'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/cache.rb:212:in `set'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/cache.rb:136:in `set'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/loader.rb:243:in `store_asset'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/loader.rb:185:in `load_from_unloaded'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/loader.rb:60:in `block in load'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/loader.rb:317:in `fetch_asset_from_dependency_cache'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/loader.rb:44:in `load'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/cached_environment.rb:20:in `block in initialize'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/cached_environment.rb:47:in `load'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/base.rb:66:in `find_asset'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/base.rb:73:in `find_all_linked_assets'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/manifest.rb:134:in `block in find'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/manifest.rb:133:in `each'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/manifest.rb:133:in `find'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/sprockets/manifest.rb:186:in `compile'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-rails-3.5.1/lib/sprockets/rails/task.rb:67:in `block (3 levels) in define'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-3.7.3/lib/rake/sprocketstask.rb:147:in `with_logger'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sprockets-rails-3.5.1/lib/sprockets/rails/task.rb:66:in `block (2 levels) in define'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Tasks: TOP => assets:precompile
(See full trace by running task with --trace)
I, [2024-07-03T15:34:04.978774 #1] INFO -- : Checking 'Add(back) Category Colmn (TH)' for 'default'... up to date
Checking '* Official: discourse-placeholder-theme-component (JP)' for 'default'... up to date
Checking '* Discourse Easy Footer (Official)' for 'default'... up to date
Checking 'discourse-user-field-prompt' for 'default'... up to date
Checking '* Rotate Global Banner(JP)' for 'default'... up to date
Checking 'Guest Gate Theme Component' for 'default'... up to date
Checking '* Official: discourse-search-banner' for 'default'... up to date
Checking '* Official: Header submenus' for 'default'... up to date
Checking '* Auto linkify words (official)' for 'default'... up to date
Checking '* Official: New PM Dropdown Button (KED)' for 'default'... up to date
Checking 'Sidebar Theme Toggle' for 'default'... up to date
Downloading MaxMindDB...
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'SKIP_EMBER_CLI_COMPILE=1 bundle exec rake themes:update assets:precompile' failed with ret
urn #<Process::Status: pid 1726 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn'
exec failed with the params {"cd"=>"$home", "tag"=>"precompile", "hook"=>"assets_precompile", "cmd"=>["su discourse -c 'SKIP_EMBER_CLI_COMPILE=1 bund
le exec rake themes:update assets:precompile'"]}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
Subsequent rebuild with the Maxmind key and id commented out succeeds.
Why is this so hard?
So here’s the limit from
I’m not quite clear how I’d be hitting these limits, but it’s the only explanation other than spurious downtime on their servers?
For me that limit triggers whenever I rebuild a server more than once per day.
I also get an email that starts like this (emphasis mine)
So apparently there is also a per-IP limit.
That’s a huge help. I have never seen that email.
I might be able to do something to keep the multiple servers on a single IP from doing that, but not being able to rebuild twice in a day seems like something of a challenge. I guess a caching proxy is the only thing I can think of.
I’d be happy to pay them some amount of money to make this not be a problem, but don’t see a way to do that.
But it’s something other than rate limits because after I built the image I went and set the values in /var/www/discourse/config/discourse.conf and ran the rake task and it downloaded the database just fine.
Could the database live in persistent storage?
Could the database be downloaded only after the image is started up?
@JammyDodger have you been able to build with Maxmind since the latest release? @RGJ – have you had any trouble?
I don’t think any sites I’ve tried with maxmind have worked. And the one that I did yesterday was able to pull down the database with the rake task after I went in an edited the config inside the container with the same settings that caused the bootstrap to fail.
There have been several other topics about failures due to Maxmind.
I had a rebuild fail even with the Maxmind account id the other day, but a second one straight after went through fine.
We haven’t had any issues, (but we’re using our own deployment system).
I have just tried it and I can retrieve the file 10 times from the same IP (and then I stopped trying)
So my “fix” to keep an error from killing the rebuild failed.
So this will be very difficult to debug.
I had that same email (and problem) after moving some forums on to a new server - so agree with OP, perhaps display an option to rebuild, or, try to fetch the db before rebuild begins giving us the option to ‘try again’ or ‘rebuild without maxmind’.
fwiw, the recent change to them requiring api key + username instead of just api key caused our upgrade/rebuild to fail as well causing a few days of downtime.
Agreed with others that disable/comment out in app.yml >> rebuild = fixed it. We haven’t re-enabled yet as waiting for whatever fix this could be.
Do you happen to have the error message of where the rebuild failed at?