Screenshots upload (deliver) failed with App Store's Rate limit exceeded error

Issue Description
I worked on two projects which have 14 languages and respectively 10 and 45 screenshots per language. We recently update our fastlane configuration to use the AppStoreConnect APIs. Since then our screenshots upload lane failed with this error

The request rate limit has been reached. - We've received too many requests for this API. Please wait and try again or slow down your request rate.

I tried to reduce the number of requests by uploading the screenshots of only one language and I waited more than a day to ensure than the AppStoreConnect API rate limitation was reseted. But I still failed with the same error.
There is the matchine Fastfile extract:

  lane :uploadScreenshots do |options|
    api_key = app_store_connect_api_key()
    deliver(
      api_key: api_key,
      submit_for_review: false,
      force: true,
      skip_metadata: true,
      skip_binary_upload: true,
      precheck_include_in_app_purchases: false,
      run_precheck_before_submit: false,
      overwrite_screenshots: options[:overwrite_screenshots]
    )
  end

Command executed
bundle exec fastlane uploadScreenshots onJenkins:true overwrite_screenshots:true
Complete output when running fastlane, including the stack trace and command used

13:07:36 [13:07:36]: ----------------------------------------
13:07:36 [13:07:36]: --- Step: Verifying fastlane version ---
13:07:36 [13:07:36]: ----------------------------------------
13:07:36 [13:07:36]: Your fastlane version 2.209.1 matches the minimum requirement of 2.23.0  ✅
13:07:36 [13:07:36]: ------------------------------
13:07:36 [13:07:36]: --- Step: default_platform ---
13:07:36 [13:07:36]: ------------------------------
13:07:36 [13:07:36]: Driving the lane 'ios uploadScreenshots' 🚀
13:07:36 [13:07:36]: ---------------------------------------
13:07:36 [13:07:36]: --- Step: app_store_connect_api_key ---
13:07:36 [13:07:36]: ---------------------------------------
13:07:36 [13:07:36]: ---------------------
13:07:36 [13:07:36]: --- Step: deliver ---
13:07:36 [13:07:36]: ---------------------
13:07:36 [13:07:36]: Successfully loaded '/Users/build/jenkins-mobility/workspace/snt/nebo-ios-upload-meta+screenshot/fastlane/Deliverfile' 📄
13:07:36 [13:07:36]: No values defined in './fastlane/Deliverfile'
13:07:36 [13:07:36]: Creating authorization token for App Store Connect API
13:07:39
13:07:39 +--------------------------------------+--------------------------+
13:07:39 |                     deliver 2.209.1 Summary                     |
13:07:39 +--------------------------------------+--------------------------+
13:07:39 | api_key                              | ********                 |
13:07:39 | submit_for_review                    | false                    |
13:07:39 | force                                | true                     |
13:07:39 | skip_metadata                        | true                     |
13:07:39 | skip_binary_upload                   | true                     |
13:07:39 | precheck_include_in_app_purchases    | false                    |
13:07:39 | run_precheck_before_submit           | false                    |
13:07:39 | overwrite_screenshots                | true                     |
13:07:39 | screenshots_path                     | ./fastlane/screenshots   |
13:07:39 | metadata_path                        | ./fastlane/metadata      |
13:07:39 | username                             | xxx         |
13:07:39 | app_identifier                       | xxx |
13:07:39 | platform                             | ios                      |
13:07:39 | edit_live                            | false                    |
13:07:39 | use_live_version                     | false                    |
13:07:39 | skip_screenshots                     | false                    |
13:07:39 | skip_app_version_update              | false                    |
13:07:39 | sync_screenshots                     | false                    |
13:07:39 | verify_only                          | false                    |
13:07:39 | reject_if_possible                   | false                    |
13:07:39 | phased_release                       | false                    |
13:07:39 | reset_ratings                        | false                    |
13:07:39 | dev_portal_team_id                   | xxx               |
13:07:39 | precheck_default_rule_level          | warn                     |
13:07:39 | ignore_language_directory_validation | false                    |
13:07:39 +--------------------------------------+--------------------------+
13:07:39
13:07:39 [13:07:39]: Will begin uploading snapshots for '3.4.1' on App Store Connect
13:07:39 [13:07:39]: Starting with the upload of screenshots...
13:07:43 [13:07:43]: Deleted 'de-DE APP_IPHONE_55' -  (1.426387 secs)
13:07:43 [13:07:43]: Deleted 'de-DE APP_IPHONE_65' -  (1.80774 secs)
13:07:44 [13:07:44]: Number of screenshots not deleted: 0
13:07:44 [13:07:44]: Successfully deleted all screenshots
13:07:48 [13:07:48]: Uploaded './fastlane/screenshots/de-DE/NeboViewer-iOS-iphone55-05-DE.png'... (2.511385 secs)
13:07:48 [13:07:48]: Uploaded './fastlane/screenshots/de-DE/NeboViewer-iOS-iphone55-01-DE.png'... (2.583887 secs)
13:07:48 [13:07:48]: Uploaded './fastlane/screenshots/de-DE/NeboViewer-iOS-iphone65-05-DE.png'... (2.583555 secs)
13:07:48 [13:07:48]: Uploaded './fastlane/screenshots/de-DE/NeboViewer-iOS-iphone55-03-DE.png'... (2.688001 secs)
13:07:48 [13:07:48]: Uploaded './fastlane/screenshots/de-DE/NeboViewer-iOS-iphone65-02-DE.png'... (2.695805 secs)
13:07:48 [13:07:48]: Uploaded './fastlane/screenshots/de-DE/NeboViewer-iOS-iphone65-01-DE.png'... (2.713813 secs)
13:07:49 [13:07:48]: Uploaded './fastlane/screenshots/de-DE/NeboViewer-iOS-iphone55-02-DE.png'... (2.77542 secs)
13:07:49 [13:07:49]: Uploaded './fastlane/screenshots/de-DE/NeboViewer-iOS-iphone55-04-DE.png'... (2.786046 secs)
13:07:49 [13:07:49]: Uploaded './fastlane/screenshots/de-DE/NeboViewer-iOS-iphone65-03-DE.png'... (2.788113 secs)
13:07:49 [13:07:49]: Uploaded './fastlane/screenshots/de-DE/NeboViewer-iOS-iphone65-04-DE.png'... (2.896881 secs)
13:07:49 [13:07:49]: Waiting for all the screenshots to finish being processed...
13:53:38 # terminated with exception (report_on_exception is true):
13:53:38 /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/api_client.rb:204:in `handle_response': The request rate limit has been reached. - We've received too many requests for this API. Please wait and try again or slow down your request rate. (Spaceship::UnexpectedResponse)
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/api_client.rb:113:in `get'
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/tunes/tunes.rb:493:in `get_app_screenshot_sets'
13:53:38 	from /Users/build/.rvm/rubies/ruby-2.7.2/lib/ruby/2.7.0/forwardable.rb:235:in `get_app_screenshot_sets'
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/models/app_screenshot_set.rb:119:in `all'
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/models/app_store_version_localization.rb:88:in `get_app_screenshot_sets'
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/deliver/lib/deliver/app_screenshot_iterator.rb:25:in `block (3 levels) in each_app_screenshot_set'
13:53:38 # terminated with exception (report_on_exception is true):
13:53:38 /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/api_client.rb:204:in `handle_response': The request rate limit has been reached. - We've received too many requests for this API. Please wait and try again or slow down your request rate. (Spaceship::UnexpectedResponse)
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/api_client.rb:113:in `get'
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/tunes/tunes.rb:493:in `get_app_screenshot_sets'
13:53:38 	from /Users/build/.rvm/rubies/ruby-2.7.2/lib/ruby/2.7.0/forwardable.rb:235:in `get_app_screenshot_sets'
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/models/app_screenshot_set.rb:119:in `all'
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/models/app_store_version_localization.rb:88:in `get_app_screenshot_sets'
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/deliver/lib/deliver/app_screenshot_iterator.rb:25:in `block (3 levels) in each_app_screenshot_set'
13:53:38 # terminated with exception (report_on_exception is true):
13:53:38 /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/api_client.rb:204:in `handle_response': The request rate limit has been reached. - We've received too many requests for this API. Please wait and try again or slow down your request rate. (Spaceship::UnexpectedResponse)
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/api_client.rb:113:in `get'
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/tunes/tunes.rb:493:in `get_app_screenshot_sets'
13:53:38 	from /Users/build/.rvm/rubies/ruby-2.7.2/lib/ruby/2.7.0/forwardable.rb:235:in `get_app_screenshot_sets'
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/models/app_screenshot_set.rb:119:in `all'
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/models/app_store_version_localization.rb:88:in `get_app_screenshot_sets'
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/deliver/lib/deliver/app_screenshot_iterator.rb:25:in `block (3 levels) in each_app_screenshot_set'
13:53:38 # terminated with exception (report_on_exception is true):
13:53:38 /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/api_client.rb:204:in `handle_response': The request rate limit has been reached. - We've received too many requests for this API. Please wait and try again or slow down your request rate. (Spaceship::UnexpectedResponse)
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/api_client.rb:113:in `get'
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/tunes/tunes.rb:493:in `get_app_screenshot_sets'
13:53:38 	from /Users/build/.rvm/rubies/ruby-2.7.2/lib/ruby/2.7.0/forwardable.rb:235:in `get_app_screenshot_sets'
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/models/app_screenshot_set.rb:119:in `all'
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/models/app_store_version_localization.rb:88:in `get_app_screenshot_sets'
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/deliver/lib/deliver/app_screenshot_iterator.rb:25:in `block (3 levels) in each_app_screenshot_set'
13:53:38 +------------------+-----------------------+
13:53:38 |               Lane Context               |
13:53:38 +------------------+-----------------------+
13:53:38 | DEFAULT_PLATFORM | ios                   |
13:53:38 | PLATFORM_NAME    | ios                   |
13:53:38 | LANE_NAME        | ios uploadScreenshots |
13:53:38 +------------------+-----------------------+
13:53:38 [13:53:38]: The request rate limit has been reached. - We've received too many requests for this API. Please wait and try again or slow down your request rate.
13:53:38
13:53:38 +------+----------------------------+-------------+
13:53:38 |                fastlane summary                 |
13:53:38 +------+----------------------------+-------------+
13:53:38 | Step | Action                     | Time (in s) |
13:53:38 +------+----------------------------+-------------+
13:53:38 | 1    | Verifying fastlane version | 0           |
13:53:38 | 2    | default_platform           | 0           |
13:53:38 | 3    | app_store_connect_api_key  | 0           |
13:53:38 | 💥   | deliver                    | 2761        |
13:53:38 +------+----------------------------+-------------+
13:53:38
13:53:38 [13:53:38]: fastlane finished with errors
13:53:38
13:53:38 Looking for related GitHub issues on fastlane/fastlane...
13:53:38
13:53:38 Found no similar issues. To create a new issue, please visit:
13:53:38 https://github.com/fastlane/fastlane/issues/new
13:53:38 Run `fastlane env` to append the fastlane environment to your issue
13:53:38 /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/api_client.rb:204:in `handle_response': \e[31m[!] The request rate limit has been reached. - We've received too many requests for this API. Please wait and try again or slow down your request rate.\e[0m (Spaceship::UnexpectedResponse)
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/api_client.rb:113:in `get'
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/tunes/tunes.rb:493:in `get_app_screenshot_sets'
13:53:38 	from /Users/build/.rvm/rubies/ruby-2.7.2/lib/ruby/2.7.0/forwardable.rb:235:in `get_app_screenshot_sets'
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/models/app_screenshot_set.rb:119:in `all'
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/models/app_store_version_localization.rb:88:in `get_app_screenshot_sets'
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/deliver/lib/deliver/app_screenshot_iterator.rb:25:in `block (3 levels) in each_app_screenshot_set'
13:53:38 /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/api_client.rb:204:in `handle_response': The request rate limit has been reached. - We've received too many requests for this API. Please wait and try again or slow down your request rate. (Spaceship::UnexpectedResponse)
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/api_client.rb:113:in `get'
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/tunes/tunes.rb:493:in `get_app_screenshot_sets'
13:53:38 	from /Users/build/.rvm/rubies/ruby-2.7.2/lib/ruby/2.7.0/forwardable.rb:235:in `get_app_screenshot_sets'
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/models/app_screenshot_set.rb:119:in `all'
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/spaceship/lib/spaceship/connect_api/models/app_store_version_localization.rb:88:in `get_app_screenshot_sets'
13:53:38 	from /Users/build/.bundle/ruby/2.7.0/gems/fastlane-2.209.1/deliver/lib/deliver/app_screenshot_iterator.rb:25:in `block (3 levels) in each_app_screenshot_set'

Environment

✅ fastlane environment ✅
Stack

Key
Value

OS
12.5.1

Ruby
3.1.2

Bundler?
true

Git
git version 2.37.0

Installation Source
~/.bundle/ruby/3.1.0/bin/fastlane

Host
macOS 12.5.1 (21G83)

Ruby Lib Dir
~/.rbenv/versions/3.1.2/lib

OpenSSL Version
OpenSSL 1.1.1n  15 Mar 2022

Is contained
false

Is homebrew
false

Is installed via Fabric.app
false

Xcode Path
/Applications/Xcode-beta.app/Contents/Developer/

Xcode Version
14.0

Swift Version
5.7

System Locale

Variable
Value

LANG
fr_FR.UTF-8
✅

LC_ALL

LANGUAGE

fastlane files:
`./fastlane/Fastfile`
# This is the minimum version number required.
# Update this, if you use features of a newer version
fastlane_version "2.23.0"

import "../_fastlane/Fastfile"

default_platform :ios

platform :ios do

  desc "Build for testing"
  lane :buildForTesting do |options|
    myscript_unlock_keychain(options) # Can not do in before_all: do not take options
    run_tests(
      clean: true,
      workspace: "xxx.xcworkspace",
      scheme: options[:scheme],
      device: 'iPad Pro (12.9-inch) (3rd generation)',
      buildlog_path: './artifact',
      configuration: 'Debug',
      derived_data_path: './derivedData',
      build_for_testing: true
    )
  end

  desc "Test without building"
  lane :testWithoutBuilding do |options|
    begin
      #destination_hash output is something like {"platform"=>"iOS Simulator", "name"=>"iPad Pro (12.9-inch) (3rd generation)"}
      destination_hash=options[:destination].split(",").map{|h| h1,h2 = h.split('='); {h1 => h2}}.reduce(:merge)
      destination_name=destination_hash["name"]
      #Disable hardware keyboards (UI tests prerequisite) and setup device's keyboards
      sh("./../_ci/scripts/setup_simulator_keyboard.sh \"#{destination_name}\"")
      sh("if [ -d '../artifact/#{options[:testPlan]}_report' ]; then echo rm -rf '../artifact/#{options[:testPlan]}_report'; else echo 'Report directory not found'; fi")
      sh("mkdir -p '../artifact/#{options[:testPlan]}_report'")
      run_tests(
        workspace: "xxx.xcworkspace",
        scheme: options[:scheme],
        configuration: 'Debug',
        derived_data_path: "./derivedData",
        #destination is prefered to device, the latter has no garranty to run on the latest iOS version
        destination: options[:destination],
        prelaunch_simulator: true,
        max_concurrent_simulators: 2,
        test_without_building: true,
        xcargs: "-testPlan #{options[:testPlan]} -resultBundleVersion 3",
        output_directory: "./artifact/#{options[:testPlan]}_report",
        #since concurrent test are not supported by xcpretty, we disable it and dump the result test bundle which is usable by xcode
        output_style: 'raw',
        result_bundle: true,
        buildlog_path: "./artifact/#{options[:testPlan]}_report"
      )
      trainer(path: "./artifact/#{options[:testPlan]}_report/UnicornNote.xcresult", output_directory: "./artifact/#{options[:testPlan]}_report", fail_build: false, xcpretty_naming: true)
      sh("mv ../artifact/#{options[:testPlan]}_report/UnicornNote.xml ../artifact/#{options[:testPlan]}_report/result.xml")
    rescue
      trainer(path: "./artifact/#{options[:testPlan]}_report/UnicornNote.xcresult", output_directory: "./artifact/#{options[:testPlan]}_report", fail_build: false, xcpretty_naming: true)
      sh("mv ../artifact/#{options[:testPlan]}_report/UnicornNote.xml ../artifact/#{options[:testPlan]}_report/result.xml")
    end
  end

  desc "Build the internal ipa"
  lane :buildInternal do |options|
    gym(
      workspace: "xxx.xcworkspace",
      scheme: options[:scheme],
      output_directory: './artifact',
      output_name: options[:scheme]+".ipa",
      xcargs: "#{options[:xcargs]} ONLY_ACTIVE_ARCH=NO",
      archive_path: "./artifact/toBeIgnored",
      clean: true,
      export_method: "development",
      export_options: {
        compileBitcode: false,
        uploadBitcode: false,
        uploadSymbols: false,
        iCloudContainerEnvironment: "Development",
      }
    )
    swiftlint(
      mode: :lint,                            # SwiftLint mode: :lint (default) or :autocorrect
      path: "XXX",
      executable: "XXX/Pods/SwiftLint/swiftlint", # The SwiftLint binary path (optional). Important if you've installed it via CocoaPods
      output_file: "artifact/swiftlint.result.html",   # The path of the output file (optional)
      reporter: "html",                       # The custom reporter to use (optional)
      config_file: "XXX/.swiftlint.yml",       # The path of the configuration file (optional)
      ignore_exit_status: false                # Allow fastlane to continue even if SwiftLint returns a non-zero exit status
    )
    swiftlint(
      mode: :lint,                            # SwiftLint mode: :lint (default) or :autocorrect
      path: "XXX",
      executable: "XX/Pods/SwiftLint/swiftlint", # The SwiftLint binary path (optional). Important if you've installed it via CocoaPods
      output_file: "artifact/swiftlint.result.xml",   # The path of the output file (optional)
      reporter: "checkstyle",                       # The custom reporter to use (optional)
      config_file: "XXX/.swiftlint.yml",       # The path of the configuration file (optional)
      ignore_exit_status: false                # Allow fastlane to continue even if SwiftLint returns a non-zero exit status
    )
  end

  desc "Build the app-store xcarchive"
  lane :buildStore do |options|
    myscript_unlock_keychain(options)
    gym(
      workspace: "XX.xcworkspace",
      scheme: options[:scheme],
      output_directory: './artifact',
      buildlog_path: './artifact',
      output_name: "toBeIgnored.ipa",
      archive_path: "./artifact/"+options[:scheme],
      xcargs: "GCC_PREPROCESSOR_DEFINITIONS='$GCC_PREPROCESSOR_DEFINITIONS ARCHIVE=1' OTHER_SWIFT_FLAGS='$(OTHER_SWIFT_FLAGS) -DARCHIVE' ONLY_ACTIVE_ARCH=NO",
      skip_package_ipa: true,
      clean: true,
      xcpretty_utf: true
    )
  end

  desc "Upload app-store ipa from app-store xcarchive"
  lane :itunesConnect do |options|
    gym(
      workspace: "XXX.xcworkspace",
      scheme: options[:scheme],
      export_options: "./build/exportPlistStore.plist",
      output_directory: './artifact',
      skip_build_archive: true,
      archive_path: "./artifact/"+options[:scheme],
      output_name: options[:uploadIPAName]+".ipa",
    )

    api_key = app_store_connect_api_key()
    pilot(
      api_key: api_key,
      ipa: "./artifact/"+options[:uploadIPAName]+".ipa",
      skip_submission: true,
      skip_waiting_for_build_processing: true,
      apple_id: options[:uploadAppleId]
    )
  end

  desc "Upload metadata to iTunes Connect"
  lane :uploadMetadata do |options|
    api_key = app_store_connect_api_key()
    deliver(
      api_key: api_key,
      submit_for_review: false,
      force: true,
      skip_screenshots: true,
      skip_binary_upload: true,
      precheck_include_in_app_purchases: false,
      run_precheck_before_submit: false
    )
  end

  lane :uploadScreenshots do |options|
    api_key = app_store_connect_api_key()
    deliver(
      api_key: api_key,
      submit_for_review: false,
      force: true,
      skip_metadata: true,
      skip_binary_upload: true,
      precheck_include_in_app_purchases: false,
      run_precheck_before_submit: false,
      overwrite_screenshots: options[:overwrite_screenshots]
    )
  end
end

`./fastlane/Appfile`
app_identifier "XXX" # The bundle identifier of your app
apple_id "XXX" # Your Apple email address

team_id "XXX"  # Developer Portal Team ID

# you can even provide different app identifiers, Apple IDs and team names per lane:
# More information: https://github.com/fastlane/fastlane/blob/master/fastlane/docs/Appfile.md

fastlane gems

Gem
Version
Update-Status

fastlane
2.209.1
✅ Up-To-Date

Loaded fastlane plugins:
No plugins Loaded
Loaded gems

Gem
Version

error_highlight
0.3.0

did_you_mean
1.6.1

bundler
2.0.2

pathname
0.2.0

cgi
0.3.1

set
1.0.2

readline-ext
0.1.4

uri
0.11.0

tsort
0.1.0

rake
13.0.6

rexml
3.2.5

CFPropertyList
3.0.5

concurrent-ruby
1.1.8

i18n
1.8.9

minitest
5.14.3

thread_safe
0.3.6

tzinfo
1.2.9

activesupport
<IP_ADDRESS>

public_suffix
5.0.0

addressable
2.8.1

httpclient
2.8.3

json
2.6.2

algoliasearch
1.27.5

artifactory
3.0.15

atomos
0.1.3

aws-eventstream
1.2.0

aws-partitions
1.626.0

aws-sigv4
1.5.1

jmespath
1.6.1

aws-sdk-core
3.140.0

aws-sdk-kms
1.58.0

aws-sdk-s3
1.114.0

babosa
1.0.4

claide
1.1.0

fuzzy_match
2.0.4

nap
1.1.0

netrc
0.11.0

ffi
1.15.3

ethon
0.14.0

typhoeus
1.4.0

cocoapods-core
1.10.1

cocoapods-deintegrate
1.0.4

cocoapods-downloader
1.4.0

cocoapods-plugins
1.0.0

cocoapods-search
1.0.0

cocoapods-trunk
1.5.0

cocoapods-try
1.2.0

colored2
3.1.2

escape
0.0.4

fourflusher
2.3.1

gh_inspector
1.1.3

molinillo
0.6.6

ruby-macho
1.4.0

nanaimo
0.3.0

xcodeproj
1.22.0

cocoapods
1.10.1

cocoapods-check
1.1.0

colored
1.2

highline
2.0.3

commander
4.6.0

declarative
0.0.20

digest-crc
0.6.4

unf_ext
<IP_ADDRESS>

unf
0.1.4

domain_name
0.5.20190701

dotenv
2.8.1

emoji_regex
3.2.3

excon
0.92.4

faraday-em_http
1.0.0

faraday-em_synchrony
1.0.0

faraday-excon
1.1.0

faraday-httpclient
1.0.1

multipart-post
2.0.0

faraday-multipart
1.0.4

faraday-net_http
1.0.1

faraday-net_http_persistent
1.2.0

faraday-patron
1.0.0

faraday-rack
1.0.0

faraday-retry
1.0.3

ruby2_keywords
0.0.5

faraday
1.10.2

http-cookie
1.0.5

faraday-cookie_jar
0.0.7

faraday_middleware
1.2.0

fastimage
2.2.6

jwt
2.5.0

memoist
0.16.2

multi_json
1.15.0

os
1.1.4

signet
0.17.0

googleauth
1.2.0

mini_mime
1.1.2

trailblazer-option
0.1.2

uber
0.1.0

representable
3.2.0

retriable
3.1.2

webrick
1.7.0

google-apis-core
0.7.0

google-apis-androidpublisher_v3
0.25.0

google-apis-playcustomapp_v1
0.10.0

google-apis-iamcredentials_v1
0.13.0

google-apis-storage_v1
0.17.0

google-cloud-env
1.6.0

google-cloud-errors
1.2.0

google-cloud-core
1.6.0

google-cloud-storage
1.39.0

mini_magick
4.11.0

naturally
2.2.1

optparse
0.1.1

plist
3.6.0

rubyzip
2.3.2

security
0.1.3

simctl
1.6.8

terminal-notifier
2.0.0

unicode-display_width
1.8.0

terminal-table
1.8.0

tty-screen
0.8.1

tty-cursor
0.7.1

tty-spinner
0.9.3

word_wrap
1.0.0

rouge
2.0.7

xcpretty
0.3.0

xcpretty-travis-formatter
1.0.1

generated on: 2022-09-06

I'm facing a similar issue with uploading screenshots but with the fastlane deliver --overwrite_screenshots command
output:
[17:11:33]: Number of screenshots not deleted: 0
[17:11:33]: Successfully deleted all screenshots
[17:11:35]: Uploaded '/Users/user/screenshots/en-US/3apple_screenshot_55.jpeg'... (1.142534 secs)
[17:11:35]: Uploaded '/Users/user/screenshots/en-US/1apple_screenshot_55.jpeg'... (1.184768 secs)
[17:11:35]: Uploaded '/Users/user/screenshots/en-US/1apple_screenshot_65.jpeg'... (1.186299 secs)
[17:11:35]: Uploaded '/Users/user/screenshots/en-US/3apple_screenshot_65.jpeg'... (1.204265 secs)
[17:11:35]: Uploaded '/Users/user/screenshots/en-US/4apple_screenshot_65.jpeg'... (1.234147 secs)
[17:11:35]: Uploaded '/Users/user/screenshots/en-US/5apple_screenshot_55.jpeg'... (1.255372 secs)
[17:11:36]: Uploaded '/Users/user/screenshots/en-US/4apple_screenshot_55.jpeg'... (1.292782 secs)
[17:11:36]: Uploaded '/Users/user/screenshots/en-US/5apple_screenshot_65.jpeg'... (1.294069 secs)
[17:11:36]: Uploaded '/Users/user/screenshots/en-US/2apple_screenshot_65.jpeg'... (1.341499 secs)
[17:11:36]: Uploaded '/Users/user/screenshots/en-US/2apple_screenshot_55.jpeg'... (1.350164 secs)
[⠙] Waiting for all the screenshots to finish being processed...

There was a similar issue reported this past March, https://github.com/fastlane/fastlane/issues/20028, but I have yet to resolve my issue. @alexmarktl could you explain how you were able to remove all languages?

Appears to be a similar if not the same issue described in this issue https://github.com/fastlane/fastlane/issues/20619

Same here.
It has started since I upgraded Fastlane to 2.209.1

Unfortunately my team and I are facing a similar issue:
Uploading complete! Uploading complete! Uploading complete! Uploading complete! Uploading complete! Uploading complete! INFO [2022-09-07 12:23:00.25]: Uploaded 'appstoreconfig/screenshots/en-US/3_iphone6Plus.jpg'... (1.114392 secs) INFO [2022-09-07 12:23:00.27]: Uploaded 'appstoreconfig/screenshots/en-US/4_iphone6Plus.jpg'... (1.123811 secs) INFO [2022-09-07 12:23:00.30]: Uploaded 'appstoreconfig/screenshots/en-US/1_iphoneXSmax.jpg'... (1.138808 secs) INFO [2022-09-07 12:23:00.34]: Uploaded 'appstoreconfig/screenshots/en-US/2_iphoneXSmax.jpg'... (1.160791 secs) INFO [2022-09-07 12:23:00.38]: Uploaded 'appstoreconfig/screenshots/en-US/3_iphoneXSmax.jpg'... (1.128168 secs) INFO [2022-09-07 12:23:00.51]: Uploaded 'appstoreconfig/screenshots/en-US/4_iphoneXSmax.jpg'... (1.250281 secs) DEBUG [2022-09-07 12:23:00.51]: Uploading jobs are completed INFO [2022-09-07 12:23:00.51]: Waiting for all the screenshots to finish being processed... DEBUG [2022-09-07 12:23:00.74]: There are still incomplete screenshots - {"UPLOAD_COMPLETE"=>16} DEBUG [2022-09-07 12:23:06.13]: There are still incomplete screenshots - {"COMPLETE"=>12, "UPLOAD_COMPLETE"=>4} DEBUG [2022-09-07 12:23:11.47]: There are still incomplete screenshots - {"COMPLETE"=>12, "UPLOAD_COMPLETE"=>4} DEBUG [2022-09-07 12:23:16.66]: There are still incomplete screenshots - {"COMPLETE"=>12, "UPLOAD_COMPLETE"=>4} DEBUG [2022-09-07 12:23:21.81]: There are still incomplete screenshots - {"COMPLETE"=>12, "UPLOAD_COMPLETE"=>4}
and then the: "There are still incomplete screenshots[...]" issue keeps hanging for hours until the job times out and fails.
This happens regardless of the region and language for the screenshots etc. Seems to be happening for the better part of last 48hours :(

The issue still valid, please do not close it.

It seems that the The request rate limit has been reached. - We've received too many requests for this API. Please wait and try again or slow down your request rate.
and  the Waiting for all the screenshots to finish being processed... are separate issues.
I've checked if this rate limits described somewhere and so far found only that:
https://developer.apple.com/forums/thread/110457
Didn't found any fastlane options allowing to slowdown the requests during the fastlane deliver run

The problem I've faced with
...
[09:36:55]: Uploaded './screenshots/ro/iphoneX_Romanian_09.png'... (3.433104764 secs)

Looking for related GitHub issues on fastlane/fastlane...

Found no similar issues. To create a new issue, please visit:
https://github.com/fastlane/fastlane/issues/new
Run `fastlane env` to append the fastlane environment to your issue
#<Thread:0x000055c0dd098b68 /var/lib/gems/2.7.0/gems/fastlane-2.210.1/deliver/lib/deliver/app_screenshot_iterator.rb:24 run> terminated with exception (report_on_exception is true):
/var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/api_client.rb:204:in `handle_response': The request rate limit has been reached. - We've received too many requests for this API. Please wait and try again or slow down your request rate. (Spaceship::UnexpectedResponse)
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/api_client.rb:113:in `get'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/tunes/tunes.rb:493:in `get_app_screenshot_sets'
	from /usr/lib/ruby/2.7.0/forwardable.rb:235:in `get_app_screenshot_sets'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/models/app_screenshot_set.rb:119:in `all'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/models/app_store_version_localization.rb:88:in `get_app_screenshot_sets'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/deliver/lib/deliver/app_screenshot_iterator.rb:25:in `block (3 levels) in each_app_screenshot_set'
#<Thread:0x000055c0dd077120 /var/lib/gems/2.7.0/gems/fastlane-2.210.1/deliver/lib/deliver/app_screenshot_iterator.rb:24 run> terminated with exception (report_on_exception is true):
/var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/api_client.rb:204:in `handle_response': The request rate limit has been reached. - We've received too many requests for this API. Please wait and try again or slow down your request rate. (Spaceship::UnexpectedResponse)
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/api_client.rb:113:in `get'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/tunes/tunes.rb:493:in `get_app_screenshot_sets'
	from /usr/lib/ruby/2.7.0/forwardable.rb:235:in `get_app_screenshot_sets'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/models/app_screenshot_set.rb:119:in `all'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/models/app_store_version_localization.rb:88:in `get_app_screenshot_sets'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/deliver/lib/deliver/app_screenshot_iterator.rb:25:in `block (3 levels) in each_app_screenshot_set'
#<Thread:0x000055c0dd077490 /var/lib/gems/2.7.0/gems/fastlane-2.210.1/deliver/lib/deliver/app_screenshot_iterator.rb:24 run> terminated with exception (report_on_exception is true):
/var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/api_client.rb:204:in `handle_response': The request rate limit has been reached. - We've received too many requests for this API. Please wait and try again or slow down your request rate. (Spaceship::UnexpectedResponse)
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/api_client.rb:113:in `get'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/tunes/tunes.rb:493:in `get_app_screenshot_sets'
	from /usr/lib/ruby/2.7.0/forwardable.rb:235:in `get_app_screenshot_sets'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/models/app_screenshot_set.rb:119:in `all'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/models/app_store_version_localization.rb:88:in `get_app_screenshot_sets'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/deliver/lib/deliver/app_screenshot_iterator.rb:25:in `block (3 levels) in each_app_screenshot_set'
#<Thread:0x000055c0dd098f00 /var/lib/gems/2.7.0/gems/fastlane-2.210.1/deliver/lib/deliver/app_screenshot_iterator.rb:24 run> terminated with exception (report_on_exception is true):
/var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/api_client.rb:204:in `handle_response': The request rate limit has been reached. - We've received too many requests for this API. Please wait and try again or slow down your request rate. (Spaceship::UnexpectedResponse)
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/api_client.rb:113:in `get'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/tunes/tunes.rb:493:in `get_app_screenshot_sets'
	from /usr/lib/ruby/2.7.0/forwardable.rb:235:in `get_app_screenshot_sets'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/models/app_screenshot_set.rb:119:in `all'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/models/app_store_version_localization.rb:88:in `get_app_screenshot_sets'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/deliver/lib/deliver/app_screenshot_iterator.rb:25:in `block (3 levels) in each_app_screenshot_set'
#<Thread:0x000055c0dd077ad0 /var/lib/gems/2.7.0/gems/fastlane-2.210.1/deliver/lib/deliver/app_screenshot_iterator.rb:24 run> terminated with exception (report_on_exception is true):
/var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/api_client.rb:204:in `handle_response': The request rate limit has been reached. - We've received too many requests for this API. Please wait and try again or slow down your request rate. (Spaceship::UnexpectedResponse)
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/api_client.rb:113:in `get'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/tunes/tunes.rb:493:in `get_app_screenshot_sets'
	from /usr/lib/ruby/2.7.0/forwardable.rb:235:in `get_app_screenshot_sets'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/models/app_screenshot_set.rb:119:in `all'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/models/app_store_version_localization.rb:88:in `get_app_screenshot_sets'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/deliver/lib/deliver/app_screenshot_iterator.rb:25:in `block (3 levels) in each_app_screenshot_set'
#<Thread:0x000055c0dd076e00 /var/lib/gems/2.7.0/gems/fastlane-2.210.1/deliver/lib/deliver/app_screenshot_iterator.rb:24 run> terminated with exception (report_on_exception is true):
/var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/api_client.rb:204:in `handle_response': The request rate limit has been reached. - We've received too many requests for this API. Please wait and try again or slow down your request rate. (Spaceship::UnexpectedResponse)
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/api_client.rb:113:in `get'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/tunes/tunes.rb:493:in `get_app_screenshot_sets'
	from /usr/lib/ruby/2.7.0/forwardable.rb:235:in `get_app_screenshot_sets'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/models/app_screenshot_set.rb:119:in `all'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/models/app_store_version_localization.rb:88:in `get_app_screenshot_sets'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/deliver/lib/deliver/app_screenshot_iterator.rb:25:in `block (3 levels) in each_app_screenshot_set'
#<Thread:0x000055c0dd099158 /var/lib/gems/2.7.0/gems/fastlane-2.210.1/deliver/lib/deliver/app_screenshot_iterator.rb:24 run> terminated with exception (report_on_exception is true):
/var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/api_client.rb:204:in `handle_response': The request rate limit has been reached. - We've received too many requests for this API. Please wait and try again or slow down your request rate. (Spaceship::UnexpectedResponse)
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/api_client.rb:113:in `get'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/tunes/tunes.rb:493:in `get_app_screenshot_sets'
	from /usr/lib/ruby/2.7.0/forwardable.rb:235:in `get_app_screenshot_sets'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/models/app_screenshot_set.rb:119:in `all'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/models/app_store_version_localization.rb:88:in `get_app_screenshot_sets'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/deliver/lib/deliver/app_screenshot_iterator.rb:25:in `block (3 levels) in each_app_screenshot_set'
#<Thread:0x000055c0dd0985a0 /var/lib/gems/2.7.0/gems/fastlane-2.210.1/deliver/lib/deliver/app_screenshot_iterator.rb:24 run> terminated with exception (report_on_exception is true):
/var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/api_client.rb:204:in `handle_response': The request rate limit has been reached. - We've received too many requests for this API. Please wait and try again or slow down your request rate. (Spaceship::UnexpectedResponse)
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/api_client.rb:113:in `get'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/tunes/tunes.rb:493:in `get_app_screenshot_sets'
	from /usr/lib/ruby/2.7.0/forwardable.rb:235:in `get_app_screenshot_sets'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/models/app_screenshot_set.rb:119:in `all'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/models/app_store_version_localization.rb:88:in `get_app_screenshot_sets'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/deliver/lib/deliver/app_screenshot_iterator.rb:25:in `block (3 levels) in each_app_screenshot_set'
#<Thread:0x000055c0dd098d20 /var/lib/gems/2.7.0/gems/fastlane-2.210.1/deliver/lib/deliver/app_screenshot_iterator.rb:24 run> terminated with exception (report_on_exception is true):
/var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/api_client.rb:204:in `handle_response': The request rate limit has been reached. - We've received too many requests for this API. Please wait and try again or slow down your request rate. (Spaceship::UnexpectedResponse)
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/api_client.rb:113:in `get'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/tunes/tunes.rb:493:in `get_app_screenshot_sets'
	from /usr/lib/ruby/2.7.0/forwardable.rb:235:in `get_app_screenshot_sets'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/models/app_screenshot_set.rb:119:in `all'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/models/app_store_version_localization.rb:88:in `get_app_screenshot_sets'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/deliver/lib/deliver/app_screenshot_iterator.rb:25:in `block (3 levels) in each_app_screenshot_set'
/var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/api_client.rb:204:in `handle_response': \e[31m[!] The request rate limit has been reached. - We've received too many requests for this API. Please wait and try again or slow down your request rate.\e[0m (Spaceship::UnexpectedResponse)
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/api_client.rb:113:in `get'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/tunes/tunes.rb:493:in `get_app_screenshot_sets'
	from /usr/lib/ruby/2.7.0/forwardable.rb:235:in `get_app_screenshot_sets'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/models/app_screenshot_set.rb:119:in `all'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/models/app_store_version_localization.rb:88:in `get_app_screenshot_sets'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/deliver/lib/deliver/app_screenshot_iterator.rb:25:in `block (3 levels) in each_app_screenshot_set'
/var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/api_client.rb:204:in `handle_response': The request rate limit has been reached. - We've received too many requests for this API. Please wait and try again or slow down your request rate. (Spaceship::UnexpectedResponse)
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/api_client.rb:113:in `get'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/tunes/tunes.rb:493:in `get_app_screenshot_sets'
	from /usr/lib/ruby/2.7.0/forwardable.rb:235:in `get_app_screenshot_sets'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/models/app_screenshot_set.rb:119:in `all'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/spaceship/lib/spaceship/connect_api/models/app_store_version_localization.rb:88:in `get_app_screenshot_sets'
	from /var/lib/gems/2.7.0/gems/fastlane-2.210.1/deliver/lib/deliver/app_screenshot_iterator.rb:25:in `block (3 levels) in each_app_screenshot_set'

I'm facing the same issue ; the problem is that the screenshots never end the process on App Store, I have checked after several days and still find screenshots in processing ; and, because of this, I can't submit the app for review

We are facing the same problem from time to time -> our Jenkins builds get stuck on this until we manually delete the screenshots in question (it is showing grey and with a cloud symbol).
When you delete it, the process wakes up and tries to upload the file again. Most of the times this helps it.
Still annoying.

Getting the same issue here.
The first attempt delivering dozens of screenshots reached the API rate limit after 1 hour waiting for the images to be processed.
Same with the second attempt.
For the  third attempt, now reducing to 1 locale, I got the error right away. I believe I must have reached a hour/day limit.
I also could not find a way to configure Fastlane  request rate, as suggested in the error message.


AppManifest Missing

The auto update feature is not working for me now. The honest answer is that appmanifest is missing. I accidently deleted it thinking I was doing something else. How do I recreate? Any help is appreciated. I need to retain my world settings and backups. I do run world backups and saves.

I uploaded the one from my client system and renamed it to match. Same game just server vs. client. I hope this works.

If you are using a staging directory, you can copy the appmanifest_376030.acf from there.
If not, the safest way would be to perform a arkmanager update --validate, which should re-create the appmanifest.


Add automatically PREFIX headers for models

It would be desirable to add autmatically the needed namespaces on the sparql queries

did you do this?

Not the way I want. By default in services, when a parameter is passed, it looks if it resembles a CURIE and if so, it will include the proper prefix. However, I'd like to have this not only for services, but for anything.


Potential bug in getOrganizationUsers

Hi.
When calling Zendesk.getOrganizationUsers() I get the following stacktrace:
java.lang.NoClassDefFoundError: com/damnhandy/uri/template/UriTemplate
at org.zendesk.client.v2.TemplateUri.(TemplateUri.java:21)
at org.zendesk.client.v2.Zendesk.tmpl(Zendesk.java:1283)
at org.zendesk.client.v2.Zendesk.getOrganizationUsers(Zendesk.java:443)
When I look at the implementation, I see that it is implemented different from Zendesk.getUsers()
getUsers() uses cnst, whereas getOrganizationUsers uses tmpl.
When running curl https://{subdomain}.zendesk.com/api/v2/organizations/{id}/users.json
-v -u {email_address}:{password} it returns the expected result.

Solved.
I needed to add the .jar for damnhandy in my lib-folder as I was working with unmanaged dependencies.


Rust print can't displayed in notebook environment

I tried the official example- https://pyo3.rs/v0.16.2/trait_bounds.html. It works well when the code is in .py file, I can see the print from python and rust. But when I use it in jupyter notebook(vscode), the rust print can not display.

Because notebook likely only redirects the Python streams while Rust prints to the OS stdout. Not much we can do about it I think...

Because notebook likely only redirects the Python streams while Rust prints to the OS stdout. Not much we can do about it I think...

Thanks for reply, I was wondering if Rust println! not work, would some other Rust logging module may work in notebook?

I don't know if anyone has written a Rust-log-to-Python-logging adapter yet.
We could provide println! etc macros in pyo3 that goes to sys.stdout - what do others think about that?

There is PySys_WriteStdout and ...Stderr.

The wurlitzer Python package may help in the shorter term. It can be loaded as an IPython extension.

It seems we can share rust log info to print in notebook in 0.19?

The wurlitzer Python package may help in the shorter term. It can be loaded as an IPython extension.
wurlitzer Python包可能在短期内有所帮助。它可以作为IPython扩展加载。

Unfortunately wurlitzer can only work with linux not windows

I don't think println will work as is, but maybe we can provide some convenient wrapper to print something to the stdout that PyThreadState holds. I'm gonna investigate that direction a bit.

Is there some alternative method to log or print rust info in jupyter env especially for windows？ Right now I must use windows terminal to run a py file and see what is going on rather than jupyter which makes me blind in jupyter env.
I have a method learn from polars which is set a trigger to make all info panic instantly.

I think we might be able to have py.stdout() and py.stderr() functions to give structures which use PySys_WriteStdout and PySys_WriteStderr ? Just need someone who's got time to play with an implementation.

I am having (possibly...) the same issue with google colab.   Output produced from println! in Rust appear correctly when running locally within either a .py file or within a ipynb in vscode.   The same notebook produces no text output in colab.   The output in colab appears instead under "Runtime / View runtime logs".   Example.

I think we might be able to have py.stdout() and py.stderr() functions to give structures which use PySys_WriteStdout and PySys_WriteStderr ? Just need someone who's got time to play with an implementation.

I gave this a try and got it to work.  See here.
It's unclear to me if my method is thread safe though.   Is it necessary to acquire the GIL when calling pyo3 ffi functions,  specifically PyObject_CallMethod, PySys_GetObject, PySys_WriteStderr, PySys_WriteStdout?   The first two of those are used only to call sys.stdout.flush().

Nice!
Yes those functions will need to be protected by the GIL. One straightforward option would be to carry the 'py lifetime on your types, so that they can only exist as long as the GIL is held.
Would you be interested in opening this as a PR against PyO3? I think these types would be welcome to exist as part of this library.

Yes those functions will need to be protected by the GIL. One straightforward option would be to carry the 'py lifetime on your types, so that they can only exist as long as the GIL is held.

OK, I thought that might be the case and have rewritten it accordingly.    I have not tried to carry the lifetime around though, since for our use we create a py.stdout() type object and then write to it over an extended time.   It seems better to acquire the GIL only momentarily as needed within the Write implementation of that object.   The stdout object is wrapped inside a LineWriter buffer, so hopefully not acquiring the GIL too frequently.

Would you be interested in opening this as a PR against PyO3? I think these types would be welcome to exist as part of this library.

Yes, I can do that.   What module should it live in?  Or I can create an "io" submodule so that pyo3::io::stdout is a drop-in replacement for std::io::stdout.
Note that this doesn't really address the issue of println! calls printing to the wrong place.   It just allows you to replace them with writeln!(pyo3::io::stdout(),...) calls.     Not a big deal for us, but likely a problem for someone with a really big codebase.

I have test macos/ubuntu/win10, only win10 couldn't print rust info in notebook


JSX element type 'SelectList' does not have any construct or call signatures.

Hi there,
i'm trying to use this library in a react native expo project with typescript but when i use it everything its working fine but i'll get this "warning" on the SelectList component "JSX element type 'SelectList' does not have any construct or call signatures."
Then i notice that when i use the setSelected function only the key object will pass.
I have checked the node modules and looks there is something wrong:

on line 1 on index.tsx JSXElementConstructor is never used
on line 195 on index.ts item.value does not exist.

i hope you guys could fix this annoying issues

Will be fixed soon, Thanks for raising this issue.

Hi, when will you fided this problem. I'm trying used, but not working for me. Trans


[8.x] Enhance route:clear command feedback

This PR makes the command show better feedback of what happened behind the scenes.
Sometimes there is no cache file to be deleted and sometimes there is a problem deleting the file,
we better show a different message according to the situation.

I do not know if it is better to use the warn method for erroneous cases, instead of info

No plans to change this at the moment.


Performance improvements under Thymeleaf 3

I'm currently implementing the layout dialect in Thymeleaf 3 using 'model processors', which makes the transition to the new event-based architecture a lot easier for me, but may cause developers to lose a lot of the performance benefits of said architecture.
So yeah, I'm concerned about performance.  Some things I should try that should help:

[ ] Create a benchmark suite to make sure further changes are headed in the right direction
[ ] Re-implement processors as tag processors
[ ] Create utility or IModel extension that can extract models from events within itself (I currently always go to the ModelFinder class, which uses the template manager to extract models, which is a very round-about way of obtaining a sub-model)
[ ] Have decorate and merge interfaces and implementations return a new decorated/merged object, instead of modifying the first argument (the target of the operation) so as to keep in line with Thymeleaf's architecture of immutability (goes hand-in-hand with implementing things as tag processors which must return changes as new models)

These can probably wait until after the 2.0.0 release if I don't want to hold that up.

See #108 for a performance issue when I load templates too often (made worse by the fact that templates are pulled over the internet).  That should be another thing to look into for performance.

Something else that's come up in talks w/ Daniel: performing model equality might be a bit of a hit, particularly for text nodes that will need to resolve their underlying CharSequence in memory.

If you like to implement benchmarks with the help of JMH, i have a benchmark profile implemented in one of my github projects.
Works pretty well to get an overview and was kind of easy to get it running. The project is small so could good for some hints :) take a look at the pom.xml
https://github.com/Antibrumm/jackson-antpathfilter/blob/master/pom.xml

Hey @Antibrumm, sorry to take so long getting back to you, but just getting layout dialect updated for Thymeleaf 3 has been keeping me busy!
Anyway, I don't know anything about JMH (I had to Google it and do some reading), but how has it been helping you and your project?

See some of the comments on the thread about a potential memory leak: https://github.com/ultraq/thymeleaf-layout-dialect/issues/122 ExpandoMetaClass came up as a memory dominator (due to my reliance on Groovy's metaprogramming features to make life much simpler for me) but it might be good to cut back on them

I did not use it in an extreme way (yet), as the library is not meant to be a high throughput piece of work at the moment. But for playing around with different possibilities of optimizations I found JMH quite helpful as the usage is very easy. Similiar to JUnit, all you have to do is place some annotations like in the code piece below and JMH takes care of the warmup phase and all the other stuff you easily forget when you write benchmarks yourself :)
In my case I write JSON dynamically based on the include/exclude pattern given to the Jackson2Helper. I wanted to measure the impact of calling serialization using wildcards, explicit path declaration and standard ObjectMapper.
@State(Scope.Benchmark)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
@Warmup(iterations = 10, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 10, time = 1, timeUnit = TimeUnit.SECONDS)
@Fork(3)
@Threads(5)
public class ComparisonBenchmark {

    private final Jackson2Helper jackson2Helper = new Jackson2Helper();
    private final List<User> users = new ArrayList<User>();
    private ObjectMapper objectMapper = new ObjectMapper();

public class ComparisonBenchmark {

    private final Jackson2Helper jackson2Helper = new Jackson2Helper();
    private final List<User> users = new ArrayList<User>();
    private ObjectMapper objectMapper = new ObjectMapper();

    public ComparisonBenchmark() {
        for (int i = 0; i < 10; i++) {
            users.add(User.buildRecursive(100));
        }
    }

    @Benchmark
    public void measureFiltered() {
        jackson2Helper.writeFiltered(users,
                "*", "**.manager.*", "**.address.streetName", "**.reports.lastName");
    }

    @Benchmark
    public void measureSpecificFilters() {
        jackson2Helper.writeFiltered(users,
                "firstName", "lastName", "email", "manager.firstName", "manager.lastName");
    }

    @Benchmark
    public void measureStandard() throws JsonProcessingException {
        objectMapper.writer().writeValueAsString(users);
    }
}
}

Have removed more uses of dynamic objects/classes as a follow-through of #122, taken to the extreme, and have found ridiculous performance gains O_o  Was gonna post some of them here but someone just raised this exact issue, so I'll post more there.

Final state of performance improvements between 2.0 and 2.1
I've uploaded the very basic web app that I was using for all of my memory tests since the first report of a memory leak in 2.0.0.  GitHub repo of that project can be found here: https://github.com/ultraq/thymeleaf-layout-dialect-benchmark
It does very little, only using layout dialect features so that other things that would normally be a part of an application don't impact the tests.  It does use Spring MVC however, which might be unnecessary overhead, but I have a good amount of faith in the Spring project's robustness such that I don't think it'll affect the results too badly.
That web app is started with the YourKit profiling agent attached, and object allocation profiling is also enabled.  The web app is then stress tested with a simple JMeter test plan (included in the repo) that simulates concurrent users and load to exaggerate any problems in the layout dialect.  At the end of the test, a forced GC is done and a memory snapshot is taken to see how the app is at rest.
Thymeleaf Layout Dialect 2.0.4

Main takeaways:

The JMeter test took about 3 minutes to complete (started around the 30 second mark), with requests taking an average of 1.674 seconds each

Old generation space at 99MB

35 garbage collections

27 million object allocations

4 seconds spent in GC

Several items taking over 10MB of retained memory (none of them appearing as dominators however, so are potentially GC'able, but don't seem to have been collected)

Majority of the object allocations taking place in the IModelExtensions.findModel closure, which uses a Groovy feature of dynamic metaclass creation

Thymeleaf Layout Dialect 2.1.0-SNAPSHOT (latest snapshot to be 2.1.0 version)

Differences:

The JMeter test took about 1 minute to complete (also started around the 30 second mark), with requests taking an average of 452ms to complete (at least 3x faster)

Old generation space at 22MB (memory footprint 1/5th the size)

21 garbage collections (40% less GCs)

1 second spent in GC (75% less time spent in GC)

Only 1 item taking over 10MB of retained memory (dominator profile looking mostly the same however)

Majority of the object allocations no longer in a Groovy dynamic meta class method, but in one of Thymeleaf's utility projects, unbescape

Changes made and lessons learned
The change that had the biggest impact to the performance profile of the layout dialect was the removal of Groovy's dynamic metaclass creation.  Here's a line representative of what that is: https://github.com/ultraq/thymeleaf-layout-dialect/blob/b9f00007e438c476b3640db7c17bdc9a7c474283/Source/nz/net/ultraq/thymeleaf/models/extensions/IModelExtensions.groovy#L211  What that line did was add a property, startIndex, to the object which I would use later on in the dialect to know exactly where a model started.  A similar property is added for where the model ended.  This was done because, in Thymeleaf 3, it did away with DOM nodes and so it was much harder for dialects to track the things that made up an "element", instead relying on queues of what it calls "events" (text, tags, comments, anything that you write into a template) with no clear demarcation of elements.
This was a huge convenience for the code, but as shown in the object allocation profiling above, something about it incurred a massive cost in memory.  This was Groovy under-the-hood code, so I don't know exactly what goes on there to provide programmers this convenience.
So I removed lines like that throughout the layout dialect, and implemented an additional step for calling code to search for the start/end of a model after the model was received.  Theoretically this should have been slower because it's an additional O(n) lookup on code that already did an O(n) lookup to retrieve the model in the first place, but practically it beat out the dynamic metaclass allocation.
Lesson learned: be careful/sparing with dynamic metaclasses.  The convenience they provide is a boon for programmers, but if in a critical part of the code its benefits may not outweigh the costs.
Notes, caveats, and final words
These numbers are specific to the benchmark that I ran them on, so don't expect to see improvements of a similar scale in your own app.  However, this all just means that the layout dialect should now be even less of a use on your own app's memory and CPU profiles, thus allowing you to focus instead on the performance of your app rather than the performance of your libraries.
If you continue to experience performance problems though, feel free to raise an issue but also provide memory profiles if at all possible.  I've actually quite enjoyed digging into and fixing up these things as I learn a lot from it in the process.


[Project]: Seismic Shifts Data Set [was Exodus]

Project Name (1 - 3 words)
Seismic Shifts
Description
Note: most of this description is out of date - see comments below
This project will take a Biweekly approach to gathering information to move along toward the goal of even defining what "exodus" is, the behaviors we see around it, and where we want to go with this research.
TASK FOR 06/05-06/13: Fill out examples of instances of people leaving a project, or events where you think people left projects in this form:
https://docs.google.com/spreadsheets/d/1KntxoZWfUxkfp1XHlDRuoWOZnpC0Y6SF3OCFJxbMihU/edit?usp=sharing
Please put anything that comes to mind, we will clean up all the examples later on!
Additional food for thought / conversation topic from the April 10, 2024 CHAOSS Data Science WG meeting:

Takeoff, but should we also consider exodus as the other side.
Plan to form a research group to look at signals before / after a mass exodus (like Redis) - what do people find using different tools. Research paper or blog might be a good outcome. This is something @cdolfi & @GaryPWhite have been talking about.
Sophia's MSR paper might also be relevant for this topic: Estimating Usage Of Open Source Projects

From Cali on Slack: A discussion in the Augur-8Knot meeting (@Gary White) came up to look at specific metrics around the xz vulnerability (repo is locked in https://github.com/tukaani-project/xz). I wanted to open it up to a broader research idea I had. Originally mine was around codebase signals before a mass exodus of a project. It would be great to organize with whoever is interested to:

Choose whether we wanted to look at the topic project exodus or malicious code vulnerability
pick a few projects that had the cited event happen
each person look at the tools/metrics they regularly use to see if there are any trends leading up to this event
See if there are any relevant conclusions from this experiment and create a blog post or otherwise with our findings

Related Links
(https://docs.google.com/spreadsheets/d/1KntxoZWfUxkfp1XHlDRuoWOZnpC0Y6SF3OCFJxbMihU/edit?usp=sharing)
How would you like to be involved in this project?
@cdolfi will take the the lead on this one!
Additional Notes.
I wanted to capture this along with the rest of the projects, but no pressure at all to work on this now. I know that Cali is on vacation / really busy at work, so this is here for whenever people are ready to tackle it.

Sheet to fill out, more context to come https://docs.google.com/spreadsheets/d/1KntxoZWfUxkfp1XHlDRuoWOZnpC0Y6SF3OCFJxbMihU/edit?usp=sharing

The idea behind this project is to build a dataset of Seismic Shifts - big things that happen to projects that are likely to cause disruptions (e.g., license changes, forks, move to foundation, acquisition, community unrest). The spreadsheet above has a start at building this dataset, which could be used by other projects to look at what happens before / after certain types of big events.


[PageContainer] Allow full-size content

Closes https://github.com/mui/toolpad/issues/4324
Needed it already in the CRUD for the list table to take up the full space in the layout.
As per the discussion in https://github.com/mui/toolpad/issues/4324:

Allow full-size content inside PageContainer with flex: 1 or height: 100%.
Add sx prop to PageContainer.
Separate PageHeader from PageContainer to optionally be used as a standalone component
Documented both the cases above

https://deploy-preview-4480--mui-toolpad-docs.netlify.app/toolpad/core/react-page-container

Looks like the CI is having out of memory issues again, we probably either need to manage dependencies to stay under or increase instance sizes?

Looks like the CI is having out of memory issues again, we probably either need to manage dependencies to stay under or increase instance sizes?

Yes, although I'm wondering what exactly triggered the CI out of memory issues

Quick comment on second thought: The PageHeader demo: https://deploy-preview-4480--mui-toolpad-docs.netlify.app/toolpad/core/react-page-container/#standalone-page-header doesn't include how it would be used with the DashboardLayout.
I'm wondering if we could show how we could use PageHeader inside the DashboardLayout versus the PageContainer, so that it doesn't break too much with the other demos. Wdyt?

On second thought:
Apart from standalone usage, should we make the PageHeader composable inside the PageContainer as well? Just as we made the ThemeSwitcher composable inside ToolbarActions?
Something like
<PageContainer>
  <PageHeader slots={{toolbar: CustomToolbar}} />
  {children}
</PageContainer>

This way, we could also move the toolbar slot to PageHeader, which better reflects its position anyway.
Wdyt? I know it's a tangential part of this PR, so feel free to extract the rest if this feels too blocking

Sounds like a probably good idea, we can discuss it just to make sure.
The only drawback from that suggestion would be that the PageContainer wouldn't as well work out of the box, but we could probably fix that by giving it a slot for the header content with PageHeader as the default?

Sounds like a probably good idea, we can discuss it just to make sure. The only drawback from that suggestion would be that the PageContainer wouldn't work as well out of the box, but we could probably fix that by giving it a slot for the header content with PageHeader as the default?

I feel we can enforce a migration now to a composable API and remove the header and toolbar slots entirely given that it is likely to be the more popular way of customization. The breaking change would have to be adding a:
<PageContainer>
+  <PageHeader>
+     <PageHeaderBreadcrumbs /> // would contain the default breadcrumbs
+    <PageHeaderToolbar> // (optional, this would replace the `toolbar` slot)
+  </PageHeader>
   {children}
 </PageContainer>

to all uses of PageContainer to get the breadcrumbs out of the box.
We can discuss this tomorrow or in next week's grooming 👍🏻

What would be the difference between PageContainer and

On second thought:
Apart from standalone usage, should we make the PageHeader composable inside the PageContainer as well? Just as we made the ThemeSwitcher composable inside ToolbarActions?
Something like
<PageContainer>
  <PageHeader slots={{toolbar: CustomToolbar}} />
  {children}
</PageContainer>

This way, we could also move the toolbar slot to PageHeader, which better reflects its position anyway.
Wdyt? I know it's a tangential part of this PR, so feel free to extract the rest if this feels too blocking

what would be the difference between the PageContainer and a @mui/material Container? Wouldn't it be enough to just build a PageHeader component?

Sounds like a probably good idea, we can discuss it just to make sure. The only drawback from that suggestion would be that the PageContainer wouldn't work as well out of the box, but we could probably fix that by giving it a slot for the header content with PageHeader as the default?

I feel we can enforce a migration now to a composable API and remove the header and toolbar slots entirely given that it is likely to be the more popular way of customization. The breaking change would have to be adding a:
<PageContainer>
+  <PageHeader>
+     <PageHeaderBreadcrumbs /> // would contain the default breadcrumbs
+    <PageHeaderToolbar> ... </PageHeaderToolbar>// (optional, this would replace the `toolbar` slot)
+  </PageHeader>
   {children}
 </PageContainer>

to all uses of PageContainer to get the breadcrumbs out of the box.
We can discuss this tomorrow or in next week's grooming 👍🏻

One of the main advantages of using Toolpad is that it does standard things for you. I feel like if we separate the container into too many sub-components that always needs to used it kind of complicates things.
I prefer the approach where we provide a few components and more detailed customization can be made with slots.

what would be the difference between the PageContainer and a @mui/material Container? Wouldn't it be enough to just build a PageHeader component?

Not a lot right now, but at the moment the PageContainer has styles that make it so that the content inside it can take up the full height inside the layout, and some default spacing around its content.
It seems like these wouldn't be difficult to do with a standard Container, especially if we provide an example on the docs on how to do full-size content in a page... So we could export the PageHeader only and include an example like that in its documentation. I could try that in this PR.


[Feat]:  add devcontainer config

Description
I would love to add .devcontainer/devcontainer.json

A devcontainer.json file can install tools and runtimes, and perform other setup tasks that the project requires.
It installs all the dependencies and runs the project automatically, allowing the developer to concentrate on coding.
A devcontainer.json file can be used to configure the development container for both codespaces and local development using Visual Studio Code.

You can try how it works by creating a codespace on the main branch in this repository.

Here is the link to the repo :https://github.com/PriyansuMaurya/Rick-and-Morty-App
Solution
You can also check : https://github.com/rupali-codes/LinksHub
Anything else?
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Hello @PriyansuMaurya; we do not need this feature at the moment on this project. We are not using containers for the project, what we would need instead is a VSCode config for now. Thank you.


Fix compatibility with Meteor 1.6

Update mongodb to 2.2.33

Otherwise the build fails with { Error: Cannot find module '../build/Release/bson'

Hi,
I have followed these instructions and this has resolved my issue with the error ({ Error: Cannot find module '../build/Release/bson') but now my upload function has broken.
When I attempt to upload I get the error...
The provided value 'undefined' is not a valid enum value of type XMLHttpRequestResponseType.
httpCall @ cfs_upload-http.js?hash=de2b2d82cc6e3296c9e82723ace0812df1773294:140
I really need this to work as I have many sites using these packages with documents uploaded already and I don't want these to stop working.
Any help would be much appreciated. If you need any further information please let me know.
Thanks, Matt.


CTRL+N not working if the focus is not on Search box.

In the search window, if the cursor is in the Search area, Ctrl  + N creates a new note without a problem.
If the cursor/focus is somewhere else, Ctrl + N does not create a new note.
Using 0.31h on Windows 10.

Thats because the Ctrl-N does not get delivered by the OS to tomboy-ng so it cannot take any action.  If you want an OS wide Ctrl-N you would need to tell your OS about it and I would need to provide a way to create a new note from the command line, both, IMHO pretty trivial additions.  I think :-)
I would add a command line switch to -ng that makes a new note when you give this command -
tomboy-ng --new-note
And you would tell your OS when ever you typed Ctrl-N it should issue the above command.
Davo

I believe you've misunderstood the situation.
Tomboy-ng Search window have a "Search" text box which is for typing. When the cursor in that textbox, CTRL+N works like a charm.
When the cursor is not in the textbox, but the Tomboy-ng window still has the active OS focus (focus on list of notes for an example, or Notebooks pane on the left), CTRL+N doesn't work. Focus is not stolen.
I don't suppose the OS would hold back sending the signals to any application when the application has the OS focus.
I hope this clears the air?

Yeah, I do, I can reproduce what you suggest. Thats definitely not as intended. Will be fixed, probably in v0.33
Thanks for reporting that !
Davo

OK, there is a experimental version in the Github Release page, https://github.com/tomboy-notes/tomboy-ng/releases/download/v0.32/tomboy-ng-setup-0.32a.exe
This package addresses two things at once, it writes a few debugln when exiting from Search Form to help debug an issue and fixes the bug reported here.  If it works for you, seems no reason why you should not use it until we push out the next formal release.
Please let me know what you find.
Davo

I confırm it works for most. It only doesn't work when the focus is on one of the checkboxes at the top: "Case sensitive" or "Auto Refresh".
This version also seems to have resolved the Right Alt + Q issue on Turkish keyboard.

It only doesn't work when the focus is on one of the checkboxes at the top: "Case sensitive" or "Auto Refresh".

Ah, I did not make key handlers for the checkboxes because they don't hold focus, maybe on Windows they do ?  That might mean we have same issue with the Speedbuttons (Refresh and Clear Filter). Further research is indicated ....
Thanks ...
Davo

OK, this issue is fixed in version 0.32b, will close.
Thanks for the report.
Davo


Make the cookiecutter more repo host agnostic

#7 raised the issue of supporting GitLab with the inclusion of a .gitlab-ci.yml file.
This issue touches on the larger issue of making the cookiecutter more hoster agnostic (right now it is very GitHubby). A few things to fix:

Only add the book url if github is selected as the hosting platform: this line
Change the user-checking functionality: this line
Create tests for other supported platforms like GitLab (this will probably be another issue)

Update with more thoughts:

I want to keep the CC as simple but functional as possible
At this point, I can only imagine GitHub and GitLab being used as hosting platforms, so let's stick with accommodating those for now
Ideally, the CC would ask a user if they were going to host on GitHub or GitLab, and then customize the following things it asks based on that response, but unfortunately this conditional format is still under dev in CC (no idea when it will be implemented, if ever)

I'm closing this for now as there hasn't been any further interest. Happy to re-visit this issue if it becomes relevant again.


Type Annotations?

Hey there!
I've been making a few contributions, and think it'd be really helpful to have some form of type annotations.
For example: https://github.com/brijeshb42/monaco-vim/blob/master/src/statusbar.js#L31
options here is actually a pretty complex object:
@param {{

bottom: boolean,
desc: string,
onKeyDown: function,
onKeyUp: function(),
onClose: function(),
prefix: string,
selectValueOnOpen: boolean}} options,
value: string,
}};

Happy to help either add Closure style annotations, or to migrate to TypeScript.

Will be possible for top level exports but I don't think it will be possible for the actual vim wrapper itself.

So are we getting anywhere with this?


Input boxes when under Ionic

I'm submitting a ...

[ ] bug report
[ ] feature request
[X] support request
[ ] other (Please specify)

Provide information & explanation
When porting over the front-end code to create an ionic app, input boxes don't let you select just any character of what you've typed in.

You have to backspace everything until you get to the character you wish to replace, and retype everything else.

Got code samples?

I don't even know where to start looking! :disappointed:
Any help would be greatly appreciated.

Laravel & Angular version: 3.0.7 according to the last entry in the CHANGELOG.md

I think they have a user-select: none on their inputs
check this stack overflow question

Awesome, thanks! :)


Ability to show "upcoming" scheduled maintenance on status pages prior to maintenance window starting

⚠ Please verify that this feature request has NOT been suggested before.

[X] I checked and didn't find similar feature request

🏷 Feature Request Type
UI Feature
🔖 Feature description
I'd love the ability to show "Scheduled Maintenance" notifications on status pages when we know there is a maintenance window scheduled. This way we can schedule maintenance any time in advance and people visiting the status page can see all upcoming maintenance windows so they can prepare.
At the moment, the "Maintenance" notification only appears on the status pages after the maintenance window has started.
✔ Solution
A checkbox to "Show advanced maintenance schedule" when adding a scheduled maintenance window.
When checked, this maintenance period will appear on the status page as "Upcoming scheduled maintenance" and display the scheduled date/time with optional description.
It could even translate the timezone based on the users browser settings.
❓ Alternatives
No response
📝 Additional Context
No response

That would be really useful feature. Actually I came here looking for exactly this, if there is such feature already, or maybe there are some open issues regarding this topic. @louislam any chance for this feature. I'm not JS developer myself, so can't help much with coding, only with eventual testing ;)

+1 on this feature. Would be awesome to show upcomming maintenance instead of ongoing.

I was asked this question today. this would actually make sense to be able to announce maintenance windows.

👍
I was a bit surprised when I scheduled a maintenance for the first time and I couldn't get it displayed on the status page. That was actually one of our main goals to have it working that way.
And should be actually pretty simple to implement.. Anyone?

I would also love to see upcoming scheduled maintenance windows on the status page. It would also be great if creating such a scheduled maintenance would send allow sending a notification. Anyway, love uptime kuma!

We would appreciate this too!

@prom00 @1fexd @evolucja @wucherpfennig @Kevinvincentals @grodzik
Please refrain from posting +1 / requests for updates things on issues, as this makes issue-management harder.
Issues are for discussing what needs to be done how by whom.
We use 👍🏻 on issues to prioritise work, as always: Pull Requests welcome.

@prom00 @1fexd @evolucja @wucherpfennig @Kevinvincentals @grodzik Please refrain from posting +1 / requests for updates things on issues, as this makes issue-management harder. Issues are for discussing what needs to be done how by whom. We use 👍🏻 on issues to prioritise work, as always: Pull Requests welcome.

I've been looking into the source, but I'm having issues on getting the system started. (db-config.json file missing).
I think we don't need major changes for this to be implemented, but I could be completely wrong with this not knowing the complete source.

The getting started docs apparrently is not quite up to date/ a better warning message might be needed:

db-config.json is the file detailing how to connect to the db
it is created in the first step of the frontends' setup wizard

Note that npm run dev serves the frontend under localhost:3000 and the server under localhost:3001

I tried starting it with
npm run dev
AND
npm run start-frontend-dev
AND
npm run start-server-dev
None of the above seemed to generate a db-config.json file.
Then I got back to thinking, I started the frontend only and accessed it via the browser. It then stated the server wasn't running.
Then I started the backend and reloaded the browser and finally managed to create the database.
It's totally missing this critical step in the docs. The docs even state you can both start them together, but then it errors out.
Think we better change this message: [SETUP-DATABASE] INFO: db-config.json is not found or invalid: ENOENT: no such file or directory, open 'data\db-config.json'
Where it hints the user to open the frontend to generate a database.

Another error throwing up trying to get this running:
Trace: [Error: insert into `stat_daily` (`down`, `monitor_id`, `ping`, `timestamp`, `up`) values (0, 3, NULL,<PHONE_NUMBER>, 29) - SQLITE_CONSTRAINT: NOT NULL constraint failed: stat_daily.ping] {   errno: 19,   code: 'SQLITE_CONSTRAINT' }
This happens everytime a monitor is tried at the heartbeat interval. Happens for every monitor configured.

This is really necessary for us

@Alex-0293 Feel free to contribute a PR
https://github.com/louislam/uptime-kuma/blob/562de6abb458a1708124f4589ab79e730913dad9/CONTRIBUTING.md


add test for snmp

snmpd manually executed listens correctly while in this frame netstat does not report anything
# sed 's/^/    /' ./server
#!/bin/bash -xe

cat > ./config << EOF
rocommunity public
EOF
ip a
/usr/sbin/snmpd -f -c ./config udp6:[::]:161 udp:<IP_ADDRESS>:161 tcp:<IP_ADDRESS>:161 tcp6:[::]:161 &
ps aux | grep snmp || :
sleep 2
ps uax | grep snmp || :
netstat -putna
wait $!
# sed 's/^/    /' ./client
#!/bin/bash -e

exec /usr/bin/snmpgetnext -v 2c -c public $DESTINATION .
# sed 's/^/    /' ./deps
net-snmp
net-snmp-utils

the client side is also killed just a while after snmpgetnext is started ~200ms

@sopos Sorry for late response.
Your netstat probably doesn't see inside the network namespaces. Debugging with network-testing must be done with care. I would like to improve that in the future. The client should be pretty quick to start. If your services work separately from network-testing, they are probably good for merging and we would fix network-testing afterwards.


Expose CommandBarDelegate to notify implementer of CommandBar events

Platforms Impacted

[x] iOS
[ ] macOS

Description of changes
There is a need for consumers of the CommandBar to be notified when scroll events occur.
Created the CommandBarDelegate that exposes a method, commandBarDidScroll(_ commandBar: CommandBar) that notifies the implementer when a scroll event occurs.
Some alternative approaches were explored including:

Utilizing NSNotification to publish event globally
Have the consumer use KVM to monitor for scroll events.

Both of these seemed less than ideal so I went with the CommandBarDelegate approach.
Verification

Verified static library compiles
Updated the CommandBarDemoController with a switch to turn on animations when the CommandBarDelegate events occur. The animation simply changes the CommandBar background color to blue and then back to the original background color. See video below.

https://user-images.githubusercontent.com/10938746/185459748-9aff1bca-4fc3-440b-af7d-e8a10e8b8f8c.mov
Pull request checklist
This PR has considered:

[x] Light and Dark appearances
[x] iOS supported versions (all major versions greater than or equal current target deployment version)
[x] VoiceOver and Keyboard Accessibility
[ ] Internationalization and Right to Left layouts
[ ] Different resolutions (1x, 2x, 3x)
[x] Size classes and window sizes (iPhone vs iPad, notched devices, multitasking, different window sizes, etc)
[ ] iPad Pointer interaction
[ ] SwiftUI consumption (validation or new demo scenarios needed)
[ ] Objective-C exposure (provide it only if needed)

Microsoft Reviewers: Open in CodeFlow

Usually for the delegate pattern we put the protocol in the same file as the object using the delegate (for example: UITableViewDelegate lives in UITableView.h). Any reason for this one to split out to a separate project?


CFFL

CFFL

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_5dyi46jbu7/clone/recipe/meta.yaml:1: missing_python: For pypi packages, python should be present in the host and run sections. Missing in host
ERROR: /tmp/abs_5dyi46jbu7/clone/recipe/meta.yaml:1: missing_python_build_tool: Python packages require a python build tool such as setuptools.
ERROR: /tmp/abs_5dyi46jbu7/clone/recipe/meta.yaml:1: missing_wheel: For pypi packages, wheel should be present in the host section
ERROR: /tmp/abs_5dyi46jbu7/clone/recipe/meta.yaml:30: missing_pip_check: For pypi packages, pip check should be present in the test commands
ERROR: /tmp/abs_5dyi46jbu7/clone/recipe/meta.yaml:41: http_url: http://easy-thumbnails.readthedocs.io/en/latest/index.html is not https
Errors were found


Strange pathfinding with NavigationPolygon

Godot version:
Godot 3.0 final
OS/device including version:
Windows 10 x64
Issue description:
Using Navigation2D's get_simple_path() produces strange and inefficient paths, especially when navigating around inside polygons. For example:

The dots represent the path connecting the sprite to the mouse, for some reason it decides to go around the square even though it could reach the mouse by going straight towards it.
Steps to reproduce:
Just create a hole in a NavigationPolygon and try to path near it. Sometimes the path isn't too inefficient, it depends on the exact shape of the polygons.
Minimal reproduction project:
navigation.zip

!!!!!!!!! I have the same problem! Was about to post the issue, but it's very similar!
It doesn't return the straigth path, it strangely take the longest route around the squad!
It also only happens from that position, from the upper right side of the squad to the down side of the squad and from the inverse route too. If I do it from the left side, it has no problems.
Also the problem is related to the X axis I think, because moving from further X, to a landing further X, it take the straight way.

@hinasis
I did some more testing, in the project I linked it seems that making the left edge of the large polygon completely straight (using snapping) solves the issues almost entirely. In my other projects with more complicated polygons this didn't help but I found a workaround that seems to be working for now. Instead of adding a new polygon inside the larger one, you make a dent in the original polygon and then close it up by dragging the vertices exactly together (you'll need to enable snapping to get it just right). It should look like this:

I still don't think the paths created with this are as efficient as possible, but at least they're not as blatantly bad as in the original picture.

In my case I did the navpoly by code, so they all were completely straight, I don't belive it's the problems.
Any way, your solution doesn't work for my case, because I add the holes by code using bodies as reference (it's a sandbox like battle arena where you can spam structures)
Hope they fix the Nav2D..
P.S: This issue is so buried, it's posible they never read it.

I added a bit of code to visualize the polys of the NavMesh in the example project, and noticed two problems:

The A* cost heuristic is not admissible, it may overestimate the actual distance:
https://github.com/godotengine/godot/blob/a74e1514206af1b8456ece2cf009b841b86b72f1/scene/2d/navigation2d.cpp#L390-L405
... since it considers the distance from the poly center point to the end point. This is a big problem here, as the poly with the shortest route is comparatively big, with a center that's far away from the optimal route.
After fixing that, the algorithm still isn't quite ideal, since it does this:
https://github.com/godotengine/godot/blob/a74e1514206af1b8456ece2cf009b841b86b72f1/scene/2d/navigation2d.cpp#L417-L423
The algorithm assumes that the shortest distance to another poly is through the nearest point on the edge to that poly, disregarding the fact that this may make the overall distance longer.
That's a problem with the algorithm itself, since it first finds a (non-optimal) path, and then tries to optimize it using string pulling. I suppose that's why the function is called get_simple_path :)

Maybe instead of the poly center, it should use the point closest to the target point within the poly to compute distance, that may make more sense, what do you think?


Cranelift: sha2 dependency introduces many new indirect dependencies

   Compiling version_check v0.9.3
   Compiling typenum v1.14.0
   Compiling opaque-debug v0.3.0
   Compiling cpufeatures v0.2.1
   Compiling generic-array v0.14.4
   Compiling block-buffer v0.9.0
   Compiling digest v0.9.0
   Compiling sha2 v0.9.8

This regresses compilation time by a couple of seconds and requires me to add them to the list of permitted dependencies in rustc at https://github.com/rust-lang/rust/blob/f8402169aaa12e7bbb9630796a8caec90a3055ca/src/tools/tidy/src/deps.rs#L236

sha2 and its dependencies already appear in the PERMITTED_DEPENDENCIES list. Is it valuable for cranelift to avoid dependencies that rustc itself already depends on?

I'm trying to keep the dependency list as small as reasonably possible.

That's definitely a good first-order principle and I share that instinct too -- but in this case I think it's worthwhile to see the context: computing a hash in the build script and checking against the manifest lets us avoid building the whole ISLE compiler, so it's replacing an even larger dependency tree.
The best option w.r.t. dependency-set size is to build without any up-to-date checks at all, but that's a huge developer-friction issue if it is the default when hacking away in a local checkout. (Forget rebuild-isle, spend time debugging mysterious issue, discover source was never updated, etc.)
One option that may be reasonable is to put the manifest check under an on-by-default feature (say check-isle-up-to-date) so that we have safety / least-surprising behavior by default, but dependents that care strongly about minimal dependencies can specify default-features = false and then turn back on the features they need. The crate as uploaded to crates.io or on main in the git repo should always have up-to-date generated source, so skipping the checks (and thus sha512-hashing) is safe. Thoughts?

One option that may be reasonable is to put the manifest check under an on-by-default feature (say check-isle-up-to-date)

That sounds great!


When altering pgpass, fix newline issue and replacing stanza for diff username

Fix dropping newline when replacing a line not the last line of a multiline pgpass file
Add additional constraint to only replace line if username also matches

Does this change work on both *nix and Windows boxes?

We can discuss whether or not this is in scope for this branch, but I notice that the module overwrites existing lines for this server (wrds-pgdata). For end users this is not an issue, as they should have only one account, but for those of us with test accounts it is disruptive.


bump to typst v0.9.0

i delete the lock file and regenerate it, otherwise it fails to compile. don't know why. I don't know how to test lsp but it seems to be working.

That was fast :) Thanks for the PR!
Lock file regeneration should be fine. I want to look into typst::export::pdf before committing to this, but otherwise code looks good, assuming testing works out.

Thank you!


change limited text area component to hooks implementation

I've changed the implementation of LimitedTextArea component to use React Hooks. I've also created and linked a sandbox snippet to demo the same --> https://codesandbox.io/s/5z2j52zvon
#36

@Chalarangelo I just opened another PR for the same #46 Can you please take a look at that. Thanks!


gzip_static on for wp-super-cache

Reference -  https://twitter.com/pnommensen/status/539164097699266560
At the time of site create we need to turn on related wp-super-cache option.
gzip_static  on doesn't fail if .gz version is not present.

Update: Support for wp-super-cache will be dropped. So this is no longer needed. #1015


Compile issues

when i download and run this code i will get un error like React/RCTBridge.h file not found. how to achieve this issue. Please help me.

@karthi431 Just to clarify, did you follow the installation instructions in the readme? There's a lot more to it than just downloading.

I'm going to assume you figured this out. Closing the issue.


B-18392 prime counseled ppm aoa link

Summary
Make the AOA download link available to a customer on Prime Counseled PPM shipments.  This should only be available once the Prime has completed counseling.  Note: this will not show on a PPM that does not have an advance requested.
How to test

Login as a milmove customer.
Create a Prime Counseled PPM shipment.
Login as a TOO and approve the shipment.
Login as a Prime counselor and complete counseling for the move.
Log back in as the milmove customer and verify that you can see the link to download the AOA packet.

Warnings

:warning:
This PR does not include changes to unit tests, even though it affects app code.

  Generated by :no_entry_sign: dangerJS against cd8b6b8a84e773ccab6f9a88914d9d4b2b829b1c


Updating Travis to use new container infrastructure.

@AdamMagaluk Can we please merge this ASAP?  Our CI builds will run 1 billion times faster.

+10


Deprecated Docker Engine Feature

Today i play a little bit with drone and see the following in my docker (v 1.13.1 on Archlinux) log:
DEPRECATED: Setting host configuration options when the container starts is deprecated and has been removed in Docker 1.12

So as this is also stated in the Docker Docs maybe someone could check if this breaks something in drone (my testings are very basic and i can not find any failures at the moment).
The only other errors in the docker log are
Error closing logger: invalid argument

just after a lot of log messages generated during the pipeline run.
As i can not find any clues about this message (besides an closed issue #1817 and docker 1.12), maybe this is related.

So as this is also stated in the Docker Docs maybe someone could check if this breaks something in drone (my testings are very basic and i can not find any failures at the moment).

@MorphBonehunter per the issue template the issue tracker is reserved for confirmed bugs. Since there is no known issue I am closing this. If we determine there is an actionable issue or bug we can re-open.

@bradrydzewski  ok, i assume using a deprecated and removed feature is a bug but you are right, it causes no error at the moment.
Do you think i should start a new discourse thread for further discussion?


Ability to see what path was requested

There needs to be a better means to tell what path was hit despite it being found in the registered paths.

Solved by #5