Database connection error in Solid Queue, but not Rails app

My syslog keeps filling up with errors like:
ActiveRecord::DatabaseConnectionError: There is an issue connecting with your hostname: <<DB SERVER IP>>. (ActiveRecord::DatabaseConnectionError)
Please check your database configuration and ensure there is a valid connection to your database.
...stack trace removed...
PG::ConnectionBad: connection to server at "<<DB SERVER IP>>", port 5432 failed: fe_sendauth: no password supplied (PG::ConnectionBad)

I'm assuming Solid Queue is using the config/database.yml from my Rails app to connect to Postgres:
production:
  <<: *default
  database: purchasing_production
  host: <<DB SERVER IP>>
  port: 5432
  username: postgres
  password: <%= ENV["POSTGRES_PASSWORD"] %>

The Rails app is able to connect fine. I have checked that the POSTGRES_PASSWORD environment variable is set. I've also verified there's only one Solid Queue process running.
Oddly enough, when I send email with the deliver_later method, the emails are properly sent. So it seems that Solid Queue is processing something, but not able to connect to the database? What am I missing here?

Looks like it can't find a server at "<". Is this an ENV var and should it be <%= ENV["DB_SERVER_IP"] %> ?
PG::ConnectionBad: connection to server at "<<DB SERVER IP>>"

Sorry, it has the actual IP address there, I've just redacted for Github.

Is it possible that action mailer is using a different queue adapter? Or are you setting solid_queue as the adapter for everything?

I'm not using a different adapter for action mailer, at least not purposely. I'm just calling the deliver_later method "bare", without any parameters. And searching through my config files, the only thing I've set is the overall queue adapter in config/production.rb, per the solid queue instructions.

How strange! That does suggest that your only Solid Queue process is able to connect to the DB just fine. Checking again the logs that you get in syslog... do you have any other clues about these coming from Solid Queue? In these logs there's nothing that would indicate that:
ActiveRecord::DatabaseConnectionError: There is an issue connecting with your hostname: <<DB SERVER IP>>. (ActiveRecord::DatabaseConnectionError)
Please check your database configuration and ensure there is a valid connection to your database.
...stack trace removed...
PG::ConnectionBad: connection to server at "<<DB SERVER IP>>", port 5432 failed: fe_sendauth: no password supplied (PG::ConnectionBad)

Since the error is about the password missing, and that lives in an environment variable, I wonder if you have something running somewhere for your app that's trying to connect to the DB in a place where the environment variable is not set, and that's not necessarily Solid Queue 🤔

do you have any other clues about these coming from Solid Queue?

Sorry. I should have included more context from the syslog:
3555501 May  1 20:58:43 purchasing solid_queue[423333]: ActiveRecord::DatabaseConnectionError: There is an issue connecting with your hostname: REDACTED. (ActiveRecord::DatabaseConnectionError)
3555502 May  1 20:58:43 purchasing solid_queue[423333]: Please check your database configuration and ensure there is a valid connection to your database.
-- stack trace removed --
3555570 May  1 20:58:43 purchasing solid_queue[423333]: Caused by:
3555571 May  1 20:58:43 purchasing solid_queue[423333]: PG::ConnectionBad: connection to server at "REDACTED", port 5432 failed: fe_sendauth: no password supplied (PG::ConnectionBad)

This does appear to be coming from Solid Queue?

@floydj, could you share some bits from the stacktrace, redacting any data you don't want to share? From these logs above, I'm not sure what might be happening 😕

Here's the full trace:
16657082 May  6 14:29:26 purchasing solid_queue[1972630]: rake aborted!
16657083 May  6 14:29:26 purchasing solid_queue[1972630]: ActiveRecord::DatabaseConnectionError: There is an issue connecting with your hostname: (READACT). (ActiveRecord::DatabaseConnectionError)
16657084 May  6 14:29:26 purchasing solid_queue[1972630]: Please check your database configuration and ensure there is a valid connection to your database.
16657085 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb:78:in `rescue in new_client'
16657086 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb:68:in `new_client'
16657087 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb:980:in `connect'
16657088 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb:992:in `reconnect'
16657089 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:685:in `block in reconnect!'
16657090 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activesupport/lib/active_support/concurrency/null_lock.rb:9:in `synchronize'
16657091 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:684:in `reconnect!'
16657092 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:786:in `block in verify!'
16657093 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activesupport/lib/active_support/concurrency/null_lock.rb:9:in `synchronize'
16657094 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:777:in `verify!'
16657095 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:794:in `connect!'
16657096 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:1000:in `block in with_raw_connection'
16657097 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activesupport/lib/active_support/concurrency/null_lock.rb:9:in `synchronize'
16657098 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:999:in `with_raw_connection'
16657099 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:1112:in `valid_raw_connection'
16657100 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb:616:in `get_database_version'
16657101 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/schema_cache.rb:374:in `database_version'
16657102 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/schema_cache.rb:70:in `database_version'
16657103 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/schema_cache.rb:200:in `database_version'
16657104 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:870:in `database_version'
16657105 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb:644:in `check_version'
16657106 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:678:in `new_connection'
16657107 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:723:in `checkout_new_connection'
16657108 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:702:in `try_to_checkout_new_connection'
16657109 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:654:in `acquire_connection'
16657110 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:353:in `checkout'
16657111 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:182:in `connection'
16657112 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract/connection_handler.rb:246:in `retrieve_connection'
16657113 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_handling.rb:287:in `retrieve_connection'
16657114 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_handling.rb:254:in `connection'
16657115 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/model_schema.rb:622:in `load_schema!'
16657116 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/attributes.rb:264:in `load_schema!'
16657117 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/encryption/encryptable_record.rb:127:in `load_schema!'
16657118 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/model_schema.rb:567:in `block in load_schema'
16657119 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/model_schema.rb:564:in `synchronize'
16657120 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/model_schema.rb:564:in `load_schema'
16657121 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/model_schema.rb:445:in `attribute_types'
16657122 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/attribute_methods.rb:256:in `_has_attribute?'
16657123 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/inheritance.rb:61:in `new'
16657124 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/persistence.rb:54:in `create!'
16657125 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/solid_queue-0.2.2/app/models/solid_queue/process.rb:15:in `register'
16657126 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/solid_queue-0.2.2/lib/solid_queue/processes/registrable.rb:24:in `register'
16657127 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activesupport/lib/active_support/callbacks.rb:403:in `block in make_lambda'
16657128 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activesupport/lib/active_support/callbacks.rb:274:in `block in simple'
16657129 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activesupport/lib/active_support/callbacks.rb:602:in `block in invoke_after'
16657130 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activesupport/lib/active_support/callbacks.rb:602:in `each'
16657131 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activesupport/lib/active_support/callbacks.rb:602:in `invoke_after'
16657132 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activesupport/lib/active_support/callbacks.rb:111:in `run_callbacks'
16657133 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/solid_queue-0.2.2/lib/solid_queue/supervisor.rb:24:in `start'
16657134 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/solid_queue-0.2.2/lib/solid_queue/supervisor.rb:14:in `start'
16657135 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/solid_queue-0.2.2/lib/solid_queue/tasks.rb:4:in `block (2 levels) in <main>'
16657136 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/rake-13.1.0/exe/rake:27:in `<top (required)>'
16657137 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/bundler-2.4.14/lib/bundler/cli/exec.rb:58:in `load'
16657138 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/bundler-2.4.14/lib/bundler/cli/exec.rb:58:in `kernel_load'
16657139 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/bundler-2.4.14/lib/bundler/cli/exec.rb:23:in `run'
16657140 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/bundler-2.4.14/lib/bundler/cli.rb:492:in `exec'
16657141 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/bundler-2.4.14/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
16657142 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/bundler-2.4.14/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
16657143 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/bundler-2.4.14/lib/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
16657144 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/bundler-2.4.14/lib/bundler/cli.rb:34:in `dispatch'
16657145 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/bundler-2.4.14/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
16657146 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/bundler-2.4.14/lib/bundler/cli.rb:28:in `start'
16657147 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/bundler-2.4.14/exe/bundle:37:in `block in <top (required)>'
16657148 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/bundler-2.4.14/lib/bundler/friendly_errors.rb:117:in `with_friendly_errors'
16657149 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/bundler-2.4.14/exe/bundle:29:in `<top (required)>'
16657150 May  6 14:29:26 purchasing solid_queue[1972630]: /usr/local/bin/bundle:25:in `load'
16657151 May  6 14:29:26 purchasing solid_queue[1972630]: /usr/local/bin/bundle:25:in `<main>'
16657152 May  6 14:29:26 purchasing solid_queue[1972630]: Caused by:
16657153 May  6 14:29:26 purchasing solid_queue[1972630]: PG::ConnectionBad: connection to server at "(READACTED)", port 5432 failed: fe_sendauth: no password supplied (PG::ConnectionBad)
16657154 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/pg-1.5.6/lib/pg/connection.rb:701:in `async_connect_or_reset'
16657155 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/pg-1.5.6/lib/pg/connection.rb:833:in `connect_to_hosts'
16657156 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/pg-1.5.6/lib/pg/connection.rb:764:in `new'
16657157 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/pg-1.5.6/lib/pg.rb:63:in `connect'
16657158 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb:69:in `new_client'
16657159 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb:980:in `connect'
16657160 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb:992:in `reconnect'
16657161 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:685:in `block in reconnect!'
16657162 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activesupport/lib/active_support/concurrency/null_lock.rb:9:in `synchronize'
16657163 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:684:in `reconnect!'
16657164 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:786:in `block in verify!'
16657165 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activesupport/lib/active_support/concurrency/null_lock.rb:9:in `synchronize'
16657166 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:777:in `verify!'
16657167 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:794:in `connect!'
16657168 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:1000:in `block in with_raw_connection'
16657169 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activesupport/lib/active_support/concurrency/null_lock.rb:9:in `synchronize'
16657170 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:999:in `with_raw_connection'
16657171 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:1112:in `valid_raw_connection'
16657172 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb:616:in `get_database_version'
16657173 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/schema_cache.rb:374:in `database_version'
16657174 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/schema_cache.rb:70:in `database_version'
16657175 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/schema_cache.rb:200:in `database_version'
16657176 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:870:in `database_version'
16657177 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb:644:in `check_version'
16657178 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:678:in `new_connection'
16657179 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:723:in `checkout_new_connection'
16657180 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:702:in `try_to_checkout_new_connection'
16657181 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:654:in `acquire_connection'
16657182 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:353:in `checkout'
16657183 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:182:in `connection'
16657184 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_adapters/abstract/connection_handler.rb:246:in `retrieve_connection'
16657185 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_handling.rb:287:in `retrieve_connection'
16657186 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/connection_handling.rb:254:in `connection'
16657187 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/model_schema.rb:622:in `load_schema!'
16657188 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/attributes.rb:264:in `load_schema!'
16657189 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/encryption/encryptable_record.rb:127:in `load_schema!'
16657190 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/model_schema.rb:567:in `block in load_schema'
16657191 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/model_schema.rb:564:in `synchronize'
16657192 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/model_schema.rb:564:in `load_schema'
16657193 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/model_schema.rb:445:in `attribute_types'
16657194 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/attribute_methods.rb:256:in `_has_attribute?'
16657195 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/inheritance.rb:61:in `new'
16657196 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activerecord/lib/active_record/persistence.rb:54:in `create!'
16657197 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/solid_queue-0.2.2/app/models/solid_queue/process.rb:15:in `register'
16657198 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/solid_queue-0.2.2/lib/solid_queue/processes/registrable.rb:24:in `register'
16657199 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activesupport/lib/active_support/callbacks.rb:403:in `block in make_lambda'
16657200 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activesupport/lib/active_support/callbacks.rb:274:in `block in simple'
16657201 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activesupport/lib/active_support/callbacks.rb:602:in `block in invoke_after'
16657202 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activesupport/lib/active_support/callbacks.rb:602:in `each'
16657203 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activesupport/lib/active_support/callbacks.rb:602:in `invoke_after'
16657204 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/bundler/gems/rails-e58d59ce489f/activesupport/lib/active_support/callbacks.rb:111:in `run_callbacks'
16657205 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/solid_queue-0.2.2/lib/solid_queue/supervisor.rb:24:in `start'
16657206 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/solid_queue-0.2.2/lib/solid_queue/supervisor.rb:14:in `start'
16657207 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/solid_queue-0.2.2/lib/solid_queue/tasks.rb:4:in `block (2 levels) in <main>'
16657208 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/rake-13.1.0/exe/rake:27:in `<top (required)>'
16657209 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/bundler-2.4.14/lib/bundler/cli/exec.rb:58:in `load'
16657210 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/bundler-2.4.14/lib/bundler/cli/exec.rb:58:in `kernel_load'
16657211 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/bundler-2.4.14/lib/bundler/cli/exec.rb:23:in `run'
16657212 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/bundler-2.4.14/lib/bundler/cli.rb:492:in `exec'
16657213 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/bundler-2.4.14/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
16657214 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/bundler-2.4.14/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
16657215 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/bundler-2.4.14/lib/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
16657216 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/bundler-2.4.14/lib/bundler/cli.rb:34:in `dispatch'
16657217 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/bundler-2.4.14/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
16657218 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/bundler-2.4.14/lib/bundler/cli.rb:28:in `start'
16657219 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/bundler-2.4.14/exe/bundle:37:in `block in <top (required)>'
16657220 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/bundler-2.4.14/lib/bundler/friendly_errors.rb:117:in `with_friendly_errors'
16657221 May  6 14:29:26 purchasing solid_queue[1972630]: /home/deployer/purchasing/shared/bundle/ruby/3.3.0/gems/bundler-2.4.14/exe/bundle:29:in `<top (required)>'
16657222 May  6 14:29:26 purchasing solid_queue[1972630]: /usr/local/bin/bundle:25:in `load'
16657223 May  6 14:29:26 purchasing solid_queue[1972630]: /usr/local/bin/bundle:25:in `<main>'
16657224 May  6 14:29:26 purchasing solid_queue[1972630]: Tasks: TOP => solid_queue:start
16657225 May  6 14:29:26 purchasing solid_queue[1972630]: (See full trace by running task with --trace)
16657226 May  6 14:29:26 purchasing systemd[1]: Starting Cleanup of Temporary Directories...
16657227 May  6 14:29:26 purchasing systemd[1]: solid_queue.service: Main process exited, code=exited, status=1/FAILURE
16657228 May  6 14:29:26 purchasing systemd[1]: solid_queue.service: Failed with result 'exit-code'.
16657229 May  6 14:29:26 purchasing systemd[1]: solid_queue.service: Consumed 8.735s CPU time.

Thanks @floydj! It definitely looks like your database.yml configuration there is missing the password for your DB.

I have checked that the POSTGRES_PASSWORD environment variable is set.

How did you check this?

How did you check this?

There are only three user accounts in the system. I logged into each, used the env command to verify.

Could you try something like this in your app to debug whether ENV["POSTGRES_PASSWORD"] is really set when the Solid Queue supervisor process is started?
File lib/tasks/solid_queue.rake:
namespace :solid_queue do
  task :log_env_variable_present do
    Rails.logger.warn('ENV["POSTGRES_PASSWORD"] defined? ' + ENV["POSTGRES_PASSWORD"].present?)
    Rails.logger.warn("Testing DB connection: #{SolidQueue::Process.count}")
  end
end

Rake::Task["solid_queue:work"].enhance [ "solid_queue:log_env_variable_present" ]

Please forgive my ignorance, but once I add that file to my app, is there any kind of task or command for me to run?

Oh, no, no worries! This would run when solid_queue:start task runs, so when you start Solid Queue as before, and it should be logged to wherever you're sending your Rails logs.

Well, it's not popping up in my logs, but when I run the command directly:
bundle exec rails solid_queue:log_env_variable_present
bin/rails aborted!
TypeError: no implicit conversion of true into String (TypeError)

    Rails.logger.warn('ENV["POSTGRES_PASSWORD"] defined? ' + ENV["POSTGRES_PASSWORD"].present?)
                                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/home/deployer/purchasing/releases/20240506150430/lib/tasks/solid_queue.rake:3:in `+'
/home/deployer/purchasing/releases/20240506150430/lib/tasks/solid_queue.rake:3:in `block (2 levels) in <main>'
Tasks: TOP => solid_queue:log_env_variable_present
(See full trace by running task with --trace)

This is odd. It's returning that it's looking for <IP_ADDRESS> and port 5434, which isn't even in my database.yml:
bundle exec rails solid_queue:start
bin/rails aborted!
ActiveRecord::ConnectionNotEstablished: connection to server at "<IP_ADDRESS>", port 5434 failed: Connection refused (ActiveRecord::ConnectionNotEstablished)
	Is the server running on that host and accepting TCP/IP connections?

Caused by:
PG::ConnectionBad: connection to server at "<IP_ADDRESS>", port 5434 failed: Connection refused (PG::ConnectionBad)
	Is the server running on that host and accepting TCP/IP connections?

Tasks: TOP => solid_queue:start
(See full trace by running task with --trace)

This sounds like it's using some default 🤔 Are you sure you haven't configured Solid Queue to use a different database?

On the other hand, if I add the production RAILS_ENV:
RAILS_ENV=production bundle exec rake solid_queue:start
[SolidQueue] Starting Dispatcher(pid=9454, hostname=REDACTED, metadata={:polling_interval=>1, :batch_size=>500})
[SolidQueue] Starting Worker(pid=9457, hostname=REDACTED, metadata={:polling_interval=>0.1, :queues=>"*", :thread_pool_size=>5})

That seems to be ok?

Are you sure you haven't configured Solid Queue to use a different database?

I haven't knowingly configured it differently. In my config/application.rb:
    config.active_job.queue_adapter = :solid_queue

Which is all I've really configured. I haven't made any changes to the solid queue config file, etc.
I use the following service file to start solid queue on startup, but I'm not seeing anything there that could be the problem:
[Unit]
Description=solid_queue for app
After=syslog.target network.target

[Service]
Type=simple
Environment=RAILS_ENV=production
WorkingDirectory=/home/deployer/purchasing/current
ExecStart=bundle exec rake solid_queue:start
ExecReload=/bin/kill -TSTP $MAINPID
ExecStop=/bin/kill -TERM $MAINPID

Environment=MALLOC_ARENA_MAX=2

RestartSec=1
Restart=on-failure

SyslogIdentifier=solid_queue

[Install]
WantedBy=default.target

This is related to the environment variable. If I temporarily plug in the actual password in my config/database.yml file, solid queue starts up without issue:
85028 May  6 16:03:00 purchasing systemd[1]: Started solid_queue for Purchasing.
85029 May  6 16:03:05 purchasing solid_queue[12380]: [SolidQueue] Starting Dispatcher(pid=12380, hostname=redacted.com, metadata={:polling_interval=>1, :batch_size=>500})
85030 May  6 16:03:05 purchasing solid_queue[12386]: [SolidQueue] Starting Worker(pid=12386, hostname=redacted.com, metadata={:polling_interval=>0.1, :queues=>"*", :thread_pool
85031 May  6 16:03:19 purchasing systemd[1]: Started Session 10 of User deployer.
85032 May  6 16:03:21 purchasing systemd[1]: session-10.scope: Deactivated successfully.
85033 May  6 16:03:21 purchasing systemd[1]: session-10.scope: Consumed 1.484s CPU time.
85034 May  6 16:07:27 purchasing solid_queue[1201]: [SolidQueue] Claimed 1 jobs

But I can't figure out why it isn't finding that ENV["POSTGRES_PASSWORD"]. It is available if I login as the deployer user that is running the solid queue process. And the process itself seems to be running alright:
systemctl --user status solid_queue
● solid_queue.service - solid_queue for Purchasing
     Loaded: loaded (/home/deployer/.config/systemd/user/solid_queue.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2024-05-06 15:20:08 UTC; 50min ago
   Main PID: 665 (bundle)
      Tasks: 19 (limit: 4666)
     Memory: 282.1M
        CPU: 1min 8.084s
     CGroup<EMAIL_ADDRESS>             ├─ 665 "solid-queue-supervisor(0.2.2): supervising 1195, 1201"
             ├─1195 "solid-queue-dispatcher(0.2.2): waiting"
             └─1201 "solid-queue-worker(0.2.2): waiting for jobs in *"

May 06 15:20:08 purchasing.camfildev.com systemd[627]: Started solid_queue for Purchasing.
May 06 15:20:15 purchasing.camfildev.com solid_queue[1195]: [SolidQueue] Starting Dispatcher(pid=1195, hostname=redacted.com, metadata={:poll>
May 06 15:20:15 purchasing.camfildev.com solid_queue[1201]: [SolidQueue] Starting Worker(pid=1201, hostname=redacted.com, metadata={:polling_>
May 06 16:07:27 purchasing.camfildev.com solid_queue[1201]: [SolidQueue] Claimed 1 jobs

It's so odd! I'm not familiar with systemctl myself, unfortunately, but I found this answer in StackOverflow that might help. Does it ring a bell?

yeah, I've been thinking this is one of those logged-in-vs-non-interactive-shell things. I'll do some digging and report back here.
Does the Solid Core team have any recommendations on how to start it on boot? I'm not really married to systemd, but couldn't find a documented way of running it, other than manually starting it.

So that is the issue - the environment variable was not being set correctly. My research told me that if I set it in /etc/environment, then it was good in any situation, but that's obviously not true.
Adding the following line to the above service service made things work:
Environment=POSTGRES_PASSWORD=my_redacted_password

Is there a more "official" recommendation on starting at boot?

I'm seeing a similar issue. Currently I'm adding stress to my solid queue setup. I'm using it to process CSV file to ingest them to a mongodb. the process itself doesn't have big impact into Postgres.
At some moment I start to get the following error and the worker container with the EC2 instance where this is running becomes inaccessible. I need to reboot the instance and then it pick up again and continues.
I, [2024-07-23T14:50:56.640378 #17]  INFO -- : SolidQueue-0.3.3 Replaced terminated Worker (5.4ms)  pid: 10570, status: 1, pid_from_status: 10570, signaled: false, stopsig: nil, termsig: nil, hostname: "10.0.XX.80-82c40617ab2c"
I, [2024-07-23T14:51:36.787079 #10585]  INFO -- : SolidQueue-0.3.3 Register Worker (70195.5ms)  pid: 10585, hostname: "10.0.XX.80-82c40617ab2c"
W, [2024-07-23T14:51:36.795630 #10585]  WARN -- : SolidQueue-0.3.3 Error registering Worker (0.1ms)  pid: 10585, hostname: "10.0.38.XX-82c40617ab2c", error: "ActiveRecord::DatabaseConnectionError There is an issue connecting to your database with your username/password, username: solorails.\n\nPlease check your database configuration to ensure the username/password are valid.\n"
I, [2024-07-23T14:51:36.815607 #10585]  INFO -- : SolidQueue-0.3.3 Started Worker (70214.6ms)  pid: 10585, hostname: "<IP_ADDRESS>-82c40617ab2c", polling_interval: 0.1, queues: "high", thread_pool_size: 4
/usr/local/bundle/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/postgresql_adapter.rb:76:in `rescue in new_client': There is an issue connecting to your database with your username/password, username: solorails. (ActiveRecord::DatabaseConnectionError)

Please check your database configuration to ensure the username/password are valid.
...

My problem was that solid queue was using old env values stored on the server. I ssh-ed into it, and manually had to check the envs with cat ~/.kamal/env/roles/solid_queue.env and it was using a previous IP address!
So all I had to do was to run kamal env push on the terminal again, to upload all new env values to the serve for the worker to use, and the restart the web server with kamal app boot


Fix metadata template object for transaction

This PR fixes the files under qiita_db/metadata_template
Few comments:

The functions to_file and create_qiime_mapping_file were missing the encoding parameter for to_csv
The SampleTemplate.delete function was checking for RawData to allow deletion of the Sample Template. This is incorrect as it should be checking for PrepTemplate.

Just one tiny comment, :+1: regardless.

Yup :+1: once that minor comment is addressed.

@ElDeveloper @antgonza comments addressed.

@josenavas there's a real failure in your latest build.

Thanks for the heads up @ElDeveloper I notice that this error is also in the upstream/transaction branch so I will pull and probably there is something that fail when everything got together...

Tests should pass now. Let them execute to make sure :smile:

:boom:


How to choose a gpu?

I have 3 gpu's available, but I only want to train the model on one.
I can't find the argument I need to set for this.
I am interested in the gpu highlighted in red.
How do I do that?

export CUDA_VISIBLE_DEVICES in your cli might help you.


Binary Search Tree

Title: Binary Search Tree in python
Name: NEHA JHA
Label: Feature Request
Assignee: ''
Define You:
✅ DevIncept Participant
Contributor
Is your feature request related to a problem? Please describe.
Its a new feature.
Describe the solution you'd like...
IMPLEMENTATION OF BINARY SEARCH TREE (BST)
Binary Search Tree is a special type of binary tree where:
1. The value of all the nodes in the left sub-tree is less than or equal to the value of the root.
2. The value of all the nodes in the right sub-tree is greater than value of the root.
3. This rule will be recursively applied to all the left and right sub-trees of the root.
Describe alternatives you've considered?
Approach to be followed (optional):
This program contains the menu-based implementation of the basic operations on a BST:
1. Insert Node into BST
2. Search Node in BST
3. Delete Node in BST
4. Print BST (inorder way)

Issue assigned. You can proceed. @neha030


Small spelling fix

@kendaleiv : Thanks for your contribution! The author(s) have been notified to review your proposed change.


go module update - toml 0.4.1

Codecov Report

Merging #1 into beta will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             beta       #1   +/-   ##
=======================================
  Coverage   43.72%   43.72%
=======================================
  Files           6        6
  Lines         526      526
=======================================
  Hits          230      230
  Misses        269      269
  Partials       27       27

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fedf58c...456b9ea. Read the comment docs.


[5.7] Pass route to custom URL formatters

Pass route for which URL is currently generated to the custom host and path formatters.

This is a part of a series of pull requests simplifying localization of URLs, more details here https://github.com/laravel/framework/pull/24048.

Could you add another test case for this functionality instead of modifying the existing one?

Sure thing! However it was exactly when writing tests that I discovered this issue https://github.com/laravel/framework/issues/24047. Thus I want to wait first for https://github.com/laravel/framework/pull/24051 to make it's way to 5.7, then rebase and add separate tests. Or should I add them already?

I'm not sure what you're asking. Are you saying that you cannot write tests until another 5.6 PR is ported to 5.7? If so, why not?

Somehow I overlooked the fact, that I don't need to test for the relative route after all.


Clears Glimmer 2 cache when we need to hot reload

Fixes https://github.com/toranb/ember-cli-hot-loader/issues/18
I tried a couple of options:

Clear all the glimmer2 cache, but only when we hot-reload. This is the approach I settled on for the reasons outlined below.
Setting the cache limit to 1 as suggested on https://github.com/toranb/ember-cli-hot-loader/issues/18#issuecomment-260765727. I'm afraid that may have some negative impacts for regular app rendering and we would have to handle cases where hotreloading is on/off, so I wanted to do something more specific.
I tried clearing only the cache for the component we're about to hot reload, just like we do pre-glimmer2, but the keys in the object are a compound of the emberId|component-name like ember143|inline-template-classic. I don't have an easy way to get the emberId, once we find out a reliable way to get it, we should probably move to this approach.

I'll test this out today on some of our apps, but at least in the dummy app it works great and it maintains backwards compatibility

It works for me!

LGTM

@MiguelMadero you planning to tag and npm publish this today?

@MiguelMadero I went ahead and published v0.1.2 on npm this morning

@GCorbel @MiguelMadero what version of ember-cli are you both using? I tried ember-cli v2.7 w/ ember v2.10.0-beta.3 and was getting full page reloads instead of hot reloading when I made a component change using the new ember-cli-hot-loader v0.1.2

@MiguelMadero I did a quick upgrade to ember-cli v2.9.1 and hot reloading does work w/ glimmer 2 now. I'm thinking we should update the README to explain that this might be a requirement for glimmer 2 users of the addon (still need to investigate why it was full page reloading w/ v2.7 of ember-cli)

@MiguelMadero I went ahead and published v0.1.2 on npm this morning

I published v0.1.2 right after the merge, see cbd42acb7848d94eba003cdfd44378155b28f11e

did a quick upgrade to ember-cli v2.9.1 and hot reloading does work w/ glimmer 2 now.

That's interesting. I was using cli 2.9 as well, not sure what would be different since we didn't change anythin gon that area.

@MiguelMadero did some additional testing w/ ember-cli v2.7.0 (w/ node v5) and all is good w/ the latest hot loader (published today v0.1.3) so I'd assume it was nothing more than operator error on my part yesterday :)

Thanks for the update and it's good to know. I was using CLI 2.7.0 yesterday as well and it worked fine.


PassthroughBuffer move and copy constructors

I'm reading through the source code and have a few questions.
I think there is a typo in the copy and move constructor of Passthroughbuffer`?
https://github.com/CopernicaMarketingSoftware/AMQP-CPP/blob/1dc169810d31110e134fbe032be009f5f8e98d73/src/passthroughbuffer.h#L111-L126
My understanding of The PassThroughBuffer is that is constructed on the stack and that the buffer is flushed when the buffer is destructed? Is the flush on destruct normal practice it took me a while to figure out ?
Wouldn't it be more efficient if ConnectionImpl owned a buffer that was reused?

I honestly don't know. The responsibility of PassthroughBuffer is to make sure that we do not pass many (small) buffers to "user space", but that we bundle small writes into bigger operations of 4096 bytes per call. This is the task of the PassthroughBuffer::append() method. The destructor then takes care of the final batch. By using a stack-based class with a destructor we use a trick to ensure that we never forget to send out the remaining bytes (because the destructor runs automatically).
I don't know if a member-variable would be more efficient, and if it is, I do I know whether this would be a significant improvement in the total performance of the library.
What is the typo you're referring to?

Thanks for the explanation it makes sense.

What is the typo you're referring to?

The copy and move constructor of passthroughbuffer takes CopiedBuffer as argument, I'm not sure that on purpose?

You were right about that, it is a typo indeed.


Player List is not updated when players leave.

The player list is not updated when a player leaves or gets disconnected during a match or in the End Game menu.
Player list is only updated when a player leaves from the lobby state.
None working senario 1

Start a match with 3 players
Disconnect one player
Finnish the match and go to Lobby

The disconnected player is now still displayed as being a part of the game
None working senario 2

Start a match with 3 players
Finnish the match and go to End Game State
Disconnect one player
Go to lobby

The disconnected player is now still displayed as being a part of the game
Working senario

Start a match with 3 players
Finnish the match and go to Lobby
Disconnect one player

The disconnected player is now removed corectly

fixed in: https://github.com/BTH-StoraSpel-DXR/SPLASH/pull/475


Return xmin auto column from subquery

Very happy user of MassTransit here - thanks for a great piece of software.
We've been integrating the EF Core outbox with Postgresql and ran into an issue with the PostgresLockStatementFormatter - it does not return xmin from the subquery so the outer query fails with column m.xmin does not exist.
This simple PR fixes that.
To really use xmin you would also have to override the RowVersion on InboxState and OutboxState like so,
var converter = new ValueConverter<byte[]?, long>(
    v => v == null ? 0 : BitConverter.ToInt64(v, 0),
    v => BitConverter.GetBytes(v));

modelBuilder.AddOutboxStateEntity(x =>
{
    x.Property(p => p.RowVersion)
        .HasColumnName("xmin")
        .HasColumnType("xid")
        .HasConversion(converter);
});

A future fix might be to make the RowVersion a uint type which would make the above override unnecessary as Npgsql would automatically map that to xmin according to the docs here - https://www.npgsql.org/efcore/modeling/concurrency.html.
ℹ Edit - just wanted to say - we do not use (and can not use) the EF Core migrations, in which case I guess the tables would have a RowVersion column created and perhaps work (I haven't tested)

I don't completely understand the whole "xmin" thing and how it relates to postgres. The doc PR that was merged suggests those names, but I don't use them and they aren't part of the default migrations.

All PostgreSQL tables have a set of implicit and hidden system columns, among which xmin holds the ID of the latest updating transaction. Since this value automatically gets updated every time the row is changed, it is ideal for use as a concurrency token.

Using the xmin system column is recommended for uses such as how RowVersion is used as that property is marked as IsRowVersion in the fluent API. Doing the same in SQL Server would create a column of type rowversion I guess - in postgres this just avoids that column since it uses xmin instead.
I understand if you don't want to merge things you don't understand, though. We are currently hosting a modified version with this change (and some others) and can happily continue doing so, but I'll happily do changes to move this forward.

I'm pretty sure this is handled under the hood by EF/npgsql when you specify .IsRowVersion() in the mapping.

https://www.npgsql.org/efcore/modeling/concurrency.html?tabs=data-annotations

Yes, if the type is uint - not byte[].

The issue in this pull request, though, is that selecting from a subquery does not give access to the xmin column of the subquery, it needs to be returned explicitly.

This is the outbox states query before the patch,
SELECT m.outbox_id, m.created, m.delivered, m.last_sequence_number, m.lock_id, m.xmin
FROM (
    SELECT * FROM "outbox_states" ORDER BY "created" LIMIT 1 FOR UPDATE SKIP LOCKED
) AS m
LIMIT 2

This is the query after the patch,
SELECT m.outbox_id, m.created, m.delivered, m.last_sequence_number, m.lock_id, m.xmin
FROM (
    SELECT *, xmin FROM "outbox_states" ORDER BY "created" LIMIT 1 FOR UPDATE SKIP LOCKED
) AS m
LIMIT 2

I'm closing this as it doesn't really explain or test the value added, or demonstrate any required change.

@phatboyg I think we've got a similar issue with Optimistic concurrency and PostGres persisted sagas.
This is the sort of query produced by MT
SELECT d."CorrelationId",
       d."Name",
       d.xmin
FROM (SELECT * FROM "EnvironmentState" FOR UPDATE) AS d
LIMIT 2

Since xmin is a hidden column it is not included with * statement and therefore does not exist for the outer query


Integration with angular material

Is this a feature request or a bug report?
It a feature request, ability to use the directive ngxError inside a md-error component.
What's gone wrong?
I have a following code:
this.form = this.fb.group({
...
email: ['', [Validators.required, Validators.email]],
...

<md-input-container ngxErrors="email">
      <input type="email" matInput placeholder="Email" formControlName="email" required>
      <md-error ngxError="required" when="dirty">Email is required</md-error>
      <md-error ngxError="email" when="dirty">Email is invalid</md-error>
 </md-input-container>

These show always both errors even input has value.
What was meant to happen?
Show both errors if input is empty or only invalid email if input has value.
Other information
I try using into a same md-error with 2 span blocks and work as expected, but break the material design and show all errors in the same line.

@carlososiel don't know if this helps you, but I've been using Material 2 and this seems to work:
  <md-input-container>
    <input mdInput
           [placeholder]="config.label"
           [formControlName]="config.name">
    <md-error ngxErrors="config.name">

          Required.

          Must be at least 8 characters long.

    </md-error>
  </md-input-container>

Thanks, mypultz!

Thanks @mtpultz, That work for me, sorry for the delay in answer. For me that issue can be closed.

No problem :) @carlososiel I think you have to close the issue


Transcribe method kills jupyter notebook kernel

Not really sure why this could be happening. I already have the vanilla openai-whisper library running smoothly in my notebook, thought I'd try this out to see if I could improve speed.
I used task manager to check CPU and memory usage, and it isn't spiking. Also tried reducing beam_size from 5 to 1, still get the same issues.
I did get this message in my anaconda environment whenever my kernel failed:
OMP: Error #15: Initializing libiomp5md.dll, but found libiomp5md.dll already initialized.
OMP: Hint This means that multiple copies of the OpenMP runtime have been linked into the program. That is dangerous, since it can degrade performance or cause incorrect results. The best thing to do is to ensure that only a single OpenMP runtime is linked into the process, e.g. by avoiding static linking of the OpenMP runtime in any library. As an unsafe, unsupported, undocumented workaround you can set the environment variable KMP_DUPLICATE_LIB_OK=TRUE to allow the program to continue to execute, but that may cause crashes or silently produce incorrect results. For more information, please see http://www.intel.com/software/products/support/.
My code is very simple, following the structure given in the readme
%%time
from faster_whisper import WhisperModel
model_size = "small"
model = WhisperModel(model_size, device="cpu", compute_type="int8")
audio = "audio_file_name"
segments, info = model.transcribe(audio, beam_size=1, vad_filter=True)
print("done")

Any help would be greatly appreciated, thanks!

Same for me! Script from instruction just kills jupyter kernel.
`model_size = "large-v2"
Run on GPU with FP16
model = WhisperModel(model_size, device="cuda",
compute_type="default", download_root='./models')
segments, _ = model.transcribe("./audios_wav_resempled/32174134.wav", language='uk')
segments = list(segments)`
I have CUDA Version: 11.6 installed.
pip install ctranslate2 already installed.
vanilla openai-whisper library also running smoothly

I think these are different issues.
@cpalappillil Do you have something else in your notebook? For example some codes related to the vanilla openai-whisper? If yes, you can try removing this part. If it still does not work, you can try the suggestion from the error message. Put these lines as the first instructions in your notebook:
import os
os["KMP_DUPLICATE_LIB_OK"] = "TRUE"

@michaelgfeldman Is there an error log? Does it work if you use device="cpu"?

Yes it does work with device="cpu" very well (using int8 or int16).
yes i have error log from jupyter logs
15:53:04.150 [error] Disposing session as kernel process died ExitCode: undefined, Reason: This version of python seems to be incorrectly compiled
(internal generated filenames are not absolute).
This may make the debugger miss breakpoints.
Related bug: http://bugs.python.org/issue1666807
/data//ASR/.conda/lib/python3.11/site-packages/traitlets/traitlets.py:2548: FutureWarning: Supporting extra quotes around strings is deprecated in traitlets 5.0. You can use 'hmac-sha256' instead of '"hmac-sha256"' if you require traitlets >=5.
warn(
/data//ASR/.conda/lib/python3.11/site-packages/traitlets/traitlets.py:2499: FutureWarning: Supporting extra quotes around Bytes is deprecated in traitlets 5.0. Use '985a8a7e-8e19-4b80-96c6-2d510fbf4e72' instead of 'b"985a8a7e-8e19-4b80-96c6-2d510fbf4e72"'.
warn(

I have good news! I was able to resolve the issue by installing cuDNN 8.9.0 and CUDA 11.6 (+ updating Nvidia drivers).
Thanks for the help!

@guillaumekln This solution works, thank you! Faster whisper is 2.5x faster than the vanilla whisper model on my device!


ENH: Enable module.json human readability

[ ] closes #230

I've implemented the code that indents and sorts module.json in .makeModule() and reformatted the actual module.json file.
Please let me know if this is something you're willing to merge. Thanks!

Is there something I can do to help get this PR merged? E.g. change target branch
Thanks!

looking into this now - thanks for the patience and contribution Cameron!

Looks good to me.  I think this is appropriate for a 0.3.4 release which will be our next one.


Adding GEP 746: Replace Cert Refs on HTTPRoute with Cross Namespace Refs from Gateway

What type of PR is this?
/kind gep
What this PR does / why we need it:
This adds GEP #746, as a follow up to my original proposal doc.
Does this PR introduce a user-facing change?:
NONE

/cc @bowei @hbagdi @howardjohn @jpeach @Miciah @youngnick

Adding a hold until we reach some consensus around this.
/hold

/lgtm

/lgtm

/lgtm

/lgtm
/approve

/hold cancel

I think we should get this one and keep discussing the self-service use-case on #763 .
/lgtm

Related https://github.com/kubernetes-sigs/gateway-api/discussions/3418


Adding more systems

I am hoping there is a way to add more than 1 system to HA. I have the integration working with my main facility. The Maintenance building has its own security system. I would like to add this in as well. In alarm.com, I can see both from 1 login and I have a seperate login for it as well.
With my main facility loaded, it does not show the connected systems only the main system. When I load a second instance of the Alarm.com integration, it shows 2 accounts integrated, however, it overwrites the sensor data I had with the original integration. They both show the same sensors.
Is there a way to do what I am wanting?

I think the way you might do this now is to edit all of the entities it to have unique names before adding additional accounts.  This is just a workaround obviously, it sounds like we need an option to add prefix to all entity ids, unique to each account.

@PerfectBake420 If you're able to get me some more information I can take a stab at fixing this. To help, please do the following:

Install the pyalarmdotcomajax adc command line tool using these instructions.
Run the "Raw JSON" command from the instructions page.
Paste here whatever shows up in the "PARTITION" and "SYSTEM" sections.

Thanks!

Closing as stale.

Any interest in picking this back up? I am in a similar situation, and would be able to provide the requested information.


[general] remove namespacing via extensions

Previously, we thought it was helpful to create namespaces by defining all classes associated with a service as an extension to that service.
For example:
extension SpeechToText {
    public class State { ... }
}

Within SpeechToText, this class could be referred to simply as State. Externally (e.g. to the application developer), it would be referred to as SpeechToText.State.
Unfortunately, in practice, this idea has turned out to be a bit of a headache:

I often create model classes and forget to set them as an extension.
Some classes appropriately (or are required to) use a prefix, such as SpeechToTextError. Externally, then, this class would be referred to as SpeechToText.SpeechToTextError, which is more verbose than we would like.
All files in the project must have a unique name, so these files are named SpeechToTextState.swift
In documentation, the class-name prefix is dropped. In other words, SpeechToText.State becomes simply State, which makes it very difficult to find all of the documentation on SpeechToText models.

As an alternative, we should consider dropping the extension and simply including the service prefix in the type name. For example, instead of SpeechToText.State, call the type SpeechToTextState. This makes the documentation much easier to read/understand, and also ensures consistency between file names and their classes.

This has been addressed with the move to the rest-kit architecture.


feature: LongToShorthandOperatorFixer - Introduction

closes https://github.com/FriendsOfPHP/PHP-CS-Fixer/issues/3515

the CS reporting seems broken, also locally it yield different results

rebased on latest and resolved conflict, no other changes

rebased, no other changes

fix prio value after rebase

rebased on lastest without other changes

Can you pls check PHPStan errors for this PR?

thanks, all green now

rebase on latest without changes

Error: Ignored error pattern #^.+no value type specified in iterable type.+.$# in path * is expected to occur 482 times, but occurred 483 times.

This is becoming a bit of a pain, can we not disable the check?

and can we run all SCA even if the first tool fails?

rebased on latest, no other changes

rebase on latest without changes


Update virtual-machine-scale-sets-deploy-app.md

Added link to the Azure document that provides further information on the process to roll out an OS upgrade across a VMSS. I also removed the link to the vmssupgrade tool since it's mentioned on the linked doc and is a bit redundant. Can add it back in though if you want to keep it on this page.

Hi @jboeshart, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Jason Boeshart). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

@jboeshart : Thanks for your contribution to the Azure documentation! The author, @gbowerman, has been notified to review your proposed change.

@jboeshart typo in the diff'd text "avialable"

Thanks @gbowerman, fixed

#sign-off thanks

@tysonn Please merge this PR.


'React/RCTBridgeModule.h' file not found

I'm experiencing this after performing manual linking.
react-native version 0.63.3

Same problem here, did you fix it? @alexkendall

I ended up using a different library.

@alexkendall Which one? It worked properly for iOS and Android? This is driving me insane

@MattiaG96 I ended up forking and using this one https://github.com/alexkendall/rn-braintree

@alexkendall I will try the same, thank you very much !


[QUERY] Individual component SemVer vs repo milestones

Query/Question
Individual libraries, such as Azure Service Bus are SemVer versioned. When a component used to be in a standalone repo, milestones where used to represent SemVer versions to be released. One of the milestone would, for example, be the next major where breaking changes would be introduced. Issues/PRs with breaking changes would be assigned that milestone.
In the current monolithic repository, milestones are used as well, but they represent sprints. Could you please point me to the documentation (sorry if it's there and I just failed to locate it) or elaborate on the methodology used to express SemVer versions in regard to milestones? Thank you.

Related: https://github.com/Azure/azure-sdk-for-net/issues/6031#issuecomment-425551043

Good question Sean!  There deserves to be more clarity here.

Hi Sean,
You have correctly caught that we are re-working how we do things a bit around here, and that includes milestones. I'm curious - are milestones a critical path to this, or are you mostly looking to understand 'What features will be in the next major and minor releases?'
If we were to provide a roadmap with what we are planning on working on next, would that cover it?
Thanks for the clarification.

Before I touch on the milestones part, let me elaborate on SemVer first.
Semantic Versioning (SemVer) is very clear about versioning of packages. It helps customers and providers clearly communicate changes and manage expectations, eliminating surprises and streamlining software updates.
Looking at the releases page, there are two problems:

There's no way to know what version of what component is being released.
Release doesn't point to the changes made (fixed bugs, added improvements, new features added, breaking changes, etc).

Anyone monitoring this repository for releases (GitHub feature) is notified almost on a daily basis but the information is a fire-hose of packages released w/o version. This could be argued as a GitHub issue.

Saying that, having a version in the release notes would save the exploration of NuGet to identify what the latest version that got shipped was. Also, the NuGet cannot provide the information about changed made in the latest release.
Example: latest release of Microsoft.Azure.CognitiveServices.FormRecognizer.
GitHub release notes link.
NuGet feed shows 0.8.0-preview version as the latest. Is it thought? Neither from the GitHub release nor from the NuGet feed it is possible to find out what changes have been released in that version.
Milestones
Milestones are extremely helpful to set expectations and identify when things will be delivered. With milestones aligned with releases, those that dependent on features or bugs can at least have an idea what to expect. For example, a breaking change would need to go into the next major version. Therefore an issue for a bug that would required a breaking change would be assigned to the next major milestone. Additional work planned for the next major would be addressed in the similar way.
Hotfixes and new features. Depending on how those categorized based on SemVer, hotfix might be released in a milestone different from a feature that was planned. Or, if possible, they'd be packaged together under the same milestone. As a 3rd party library developer it helps to see this information to know how to plan work on my end, rather than wondering what will happen.
An example of how milestones worked for Service Bus client: link

@kurtsung @maggiepint hope this information helps.
Here's how we leverage milestones (past and  future) and releases.

Hey Sean,
I think on the releases side you are asking for work that is already in-flight. As you noticed, we are making quite a few changes to how SDKs are versioned. If you were to look at this release, it uses our new release format, which will soon be the format for all GitHub releases going forward. This follows our SemVer guidelines which over time will be enforced for all packages in this repo, including any future releases of the Service Bus client.
I realize the notes are sparse on the release I linked - I'm currently working with our dev teams to make sure we get as complete of notes as possible on our releases in the future.
Does that answer your release question?
On the milestone side - right now it's up to each service team to determine how they want to publish roadmaps/timelines/expectations. I can definitely talk to service bus about how they want to handle roadmap in this new repo format. @jsquire might be a good starting point for this.

@maggiepint the new release format is good. With some improvements to the release notes it will be exactly what I'm asking for 🙂
👍 for sorting out milestones.

any issues filed or pull requests made will continue to be actively triaged collaboratively between the Service Bus and Developer Platform teams.

👍

I think if we are happy with the new release format, then I can close this with a note that I am working on a proposal for how our service teams can track milestones and upcoming changes a bit more transparently.
Let me know if I need to re-open.


Updated requirements for pip 6.0+ to include a session

Installing robobrowser with pip 6.0+ was failing due to:
TypeError: parse_requirements() missing 1 required keyword argument: 'session'
Fixed setup.py to include a session.

Fixed the pull request as per @reversefold comments. I'm slighly worried it could break installation from previous pip versions though...

pip.download.PipSession was introduced at the same time as the session kwarg to parse_requirements, in pip 1.5, so you're not losing support for anything by using the correct value for the param.

+1

+1
Travis CI seems to have upgraded their pip so now my builds are failing.

when will it be fixed ? I see many related pr

Thanks for the patch! I wound up fixing this by skipping parse_requirements entirely in 4878ed3c5e7f0337fd056739c95c0a7063e11386.


Update opentelemetry-overview.md

Following should be added to elaborate nuances of manual instrumentation:
"This means that you have to manage the updates to the latest package version by yourself. You can use this option if you need to make custom dependency calls or API calls that are not captured by default with autoinstrumentation."

@AaronMaxwell
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team


hangs in OSX Leopard, ruby 1.9.2 at start

I tried hijacking irb and get the "hijacking ..." status.
As mentioned elsewhere, i did connect to the irb process using gdb and then run bt.
Here is part of the output:
#35 0x00000001001610d5 in rb_catch_obj (tag=4050190, func=0x10017d7a0 <catch_i>, data=0) at vm_eval.c:1523
#36 0x0000000100161b00 in rb_f_catch (argc=<value temporarily unavailable, due to optimizations>, argv=<value temporarily unavailable, due to optimizations>) at vm_eval.c:1499
#37 0x0000000100165487 in vm_call_cfunc [inlined] () at /Users/rahul/.rvm/src/ruby-1.9.2-head/vm_insnhelper.c:401
#38 0x0000000100165487 in vm_call_method (th=0x1003016a0, cfp=0x1004ffce8, num=1, blockptr=0x1004ffd11, flag=8, id=<value temporarily unavailable, due to optimizations>, me=0x10031d590, recv=4321140880) at vm_insnhelper.c:523
#39 0x0000000100168215 in vm_exec_core (th=0x1003016a0, initial=<value temporarily unavailable, due to optimizations>) at insns.def:1006
#40 0x000000010016fe53 in vm_exec (th=0x1003016a0) at vm.c:1145
#41 0x000000010017d9e1 in catch_i (tag=3214606, data=<value temporarily unavailable, due to optimizations>) at vm.c:557
#42 0x00000001001610d5 in rb_catch_obj (tag=3214606, func=0x10017d7a0 <catch_i>, data=0) at vm_eval.c:1523
#43 0x0000000100161b00 in rb_f_catch (argc=<value temporarily unavailable, due to optimizations>, argv=<value temporarily unavailable, due to optimizations>) at vm_eval.c:1499
#44 0x0000000100165487 in vm_call_cfunc [inlined] () at /Users/rahul/.rvm/src/ruby-1.9.2-head/vm_insnhelper.c:401
#45 0x0000000100165487 in vm_call_method (th=0x1003016a0, cfp=0x1004ffea0, num=1, blockptr=0x1004ffec9, flag=8, id=<value temporarily unavailable, due to optimizations>, me=0x10031d590, recv=4303825320) at vm_insnhelper.c:523
#46 0x0000000100168215 in vm_exec_core (th=0x1003016a0, initial=<value temporarily unavailable, due to optimizations>) at insns.def:1006
#47 0x000000010016fe53 in vm_exec (th=0x1003016a0) at vm.c:1145
#48 0x0000000100170158 in rb_iseq_eval_main (iseqval=4303807640) at vm.c:1386
#49 0x000000010003f0d2 in ruby_exec_internal (n=0x10086e498) at eval.c:214
#50 0x0000000100041a5c in ruby_exec_node [inlined] () at /Users/rahul/.rvm/src/ruby-1.9.2-head/eval.c:261
#51 0x0000000100041a5c in ruby_run_node (n=<value temporarily unavailable, due to optimizations>) at eval.c:254
#52 0x0000000100000ecf in main (argc=7, argv=0x7fff5fbfcfe0) at main.c:35

I am facing a similar issue:
http://stackoverflow.com/questions/7865320/hijack-hangs-on-macosx-snow-leopard
====
I just discovered [hijack][1] for ruby debugging. I installed the gem and gave it a try with thin. I grabbed the id of the thin process and passed it to hijack.
$ bundle exec thin start -d -p 3001

$ ps -axf | grep thin
501 52622 34344   0   0:01.90 ttys002    0:07.07 ruby /Users/myself/.rvm/gems/ruby-1.8.7-p352/bin/thin start -p 3001

$ hijack 52622
=> Hijacking...

Instead of giving me an IRB, it stucks after "Hijacking..."
Any ideas?
(OSX 10.6.7, Rails 2.3.8, Ruby 1.8.7)


Tag Manager and Analytics Boilerplate

Hey Philip - I think this setup is excellent and have implemented various solutions for certain autotrack plugins (page scroll, clean URLs). However, it's not clear if using the boilerplate and GTM are mutually exclusive?
Is implementing with GTM possible/recommended? If so, any tips/gotchas?
Cheers!

Same question here.

Phil answered this over on the autotrack repo earlier, reposting his comment here:

gtag doesn't support tasks or plugins, so it's not really possible to do the advanced things autotrack does with it. Unless the gtag library is updated to support these features, I don't think it makes sense to make autotrack work with gtag.

And just to be clear, I think it's worth pointing out that gtag is it's not really an analytics.js replacement; instead, it's a wrapper library on top of analytics.js (and others), meaning the gtag library still needs to load analytics.js, and it still needs to convert all relevant gtag commands to analytics.js commands to run them.

As of right now, gtag is 54.5K and analytics.js is 33.7K, and since gtag will also load analytics.js, it's 262% more code for (in my opinion) less functionality. There's also the problem that gtag is site-specific (because you add your tracking ID as a query string), so it's unlikely your users will have it cached; analytics.js on the other hand is used all over the web, so it's very likely to already be in your visitors cache when they load your site.

For these reasons, I'd strongly recommend autotrack users continue to use analytics.js instead of gtag. The only time I think it makes sense to use gtag is if you're also using other gtag-enabled Google tags, e.g. Adwords.

philipwalton commented on Oct 3, 2017


Follow-up might be needed for buildMaterializations in DialectConversion

Just a quick report that I encountered during the rebasing to the latest upstream.
There were regressions in some control flow tests like test_while. It was due to the recent MLIR update: https://github.com/llvm/llvm-project/pull/107109, which introduced ConversionConfig.buildMaterializations. This MLIR change caused creating UnrealizedConversionCastOp to fail at the following point:
https://github.com/triton-lang/triton-cpu/blob/9f98d53338bc5a2cbf388acbaca79c2762a90e60/third_party/cpu/lib/TritonToTritonCPU/TypeConverter.cpp#L27-L33
In the fix commit, https://github.com/triton-lang/triton-cpu/commit/9f98d53338bc5a2cbf388acbaca79c2762a90e60, I disabled this new feature, setting ConversionConfig.buildMaterializations as false. We might follow up later.

https://github.com/triton-lang/triton-cpu/pull/154


CI job getting a node it shouldn't get

In my kogito-images PR job, the job is failing, because it is getting a wrong node. See log here:
https://ci-builds.apache.org/job/KIE/job/kogito/job/main/job/pullrequest/job/kogito-images.build-and-test/97/console

Should be solved by
https://github.com/apache/incubator-kie-kogito-pipelines/pull/1184

I see the PR merged. Can we close this issue then please? Or does it need some more testing?


Populate systems with output from source(s)

Before the change, we didn't anything with the instances
returned from the source.
This change makes sure the system on which the query was performed,
also updates its models with the instances returned from the source

Do we want to leave the move to AttributeDictValue to another PR, include it in this one, or in my PR with the jenkins source update? I would prefer to have it in a working state to be able to test before merging both.


joplin-desktop: 1.3.18 -> 1.4.15

Motivation for this change
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Simple version bump.
Minor change: filename of the desktop icon has changed.


chore: Dependency Review Action

Dependency review is a tool that helps you identify and fix vulnerabilities in your dependencies. By checking the dependency reviews in a pull request and changing any dependencies that are flagged as vulnerable, the project can avoid vulnerabilities being added to your project. https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review#dependency-review-enforcement

So

Dependency Review seems to be a brand new action from GitHub.
It warns about dependency changes that have vulnerabilities -- so the exact same thing Dependabot does, but on PRs instead of a cron job?
Dependency review includes details of changes to indirect dependencies -- (this should not affect us as we try to keep everything listed in requirements files). It seems to do this by using the dependency graph api however so a different mechanism: we're now using a Github service to get our dependency graph instead of just running software developed by github...

What it actually changes in the workflow is buried three links deep in the docs but the result seems to be this in the review UI:

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 98.326%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1187

Relevant Lines:
1203

💛  - Coveralls


fix(rbac): handle ':' and '/' in role name

Description
Creating role with name that contains ':' or '/' creates role that can't be used.
Changes:

handles ':' in role name

invalidates '/' in role name or namespace

Fixes
https://issues.redhat.com/browse/RHIDP-3580

Maybe we should consider as valid role/group/user names only:
[a-zA-Z0-9], [-_.]


[brew cask install java] sudo: sorry, you are not allowed to preserve the environment

General troubleshooting steps

[Y] I have retried my command with --force and the issue is still present.
[Y] I have checked the instructions for reporting bugs (or making requests) before opening the issue.

[Y] None of the templates was appropriate for my issue, or I’m not sure.

[Y] I ran brew update-reset && brew update and retried my command.
[Y] I ran brew doctor, fixed as many issues as possible and retried my command.
[Y] I understand that if I ignore these instructions, my issue may be closed without review.

Description of issue
When trying to install java, I get a sudo error like this closed (without review) ticket: https://github.com/caskroom/homebrew-cask/issues/9886
(I did not try to modify the /private/etc/sudoers file as a workaround.)
Output of your command with --verbose --debug
$ brew cask install --force --verbose --debug java
==> Hbc::Installer#install
==> Printing caveats
==> Caveats
This Cask makes minor modifications to the JRE to prevent issues with
packaged applications, as discussed here:

  https://bugs.eclipse.org/bugs/show_bug.cgi?id=411361

If your Java application still asks for JRE installation, you might need
to reboot or logout/login.

Installing this Cask means you have AGREED to the Oracle Binary Code
License Agreement for Java SE at

  https://www.oracle.com/technetwork/java/javase/terms/license/index.html

==> Hbc::Installer#fetch
==> Satisfying dependencies
==> Downloading
==> Downloading http://download.oracle.com/otn-pub/java/jdk/9.0.1+11/jdk-9.0.1_osx-x64_bin.dmg
Already downloaded: /Users/jbard/Library/Caches/Homebrew/Cask/java--9.0.1,11.dmg
==> Downloaded to -> /Users/jbard/Library/Caches/Homebrew/Cask/java--9.0.1,11.dmg
==> Verifying download
==> Determining which verifications to run for Cask java
==> Checking for verification class Hbc::Verify::Checksum
==> 1 verifications defined
Hbc::Verify::Checksum
==> Running verification of class Hbc::Verify::Checksum
==> Verifying checksum for Cask java
==> SHA256 checksums match
==> Installing Cask java
==> Hbc::Installer#stage
==> Extracting primary container
==> Determining which containers to use based on filetype
==> Checking container class Hbc::Container::Pkg
==> Checking container class Hbc::Container::Ttf
==> Checking container class Hbc::Container::Otf
==> Checking container class Hbc::Container::Air
==> Checking container class Hbc::Container::Cab
==> Checking container class Hbc::Container::Dmg
==> Executing: ["/usr/bin/hdiutil", "imageinfo", "/Users/jbard/Library/Caches/Homebrew/Cask/java--9.0.1,11.dmg"]
==> Using container class Hbc::Container::Dmg for /Users/jbard/Library/Caches/Homebrew/Cask/java--9.0.1,11.dmg
==> Executing: ["/usr/bin/hdiutil", "attach", "-plist", "-nobrowse", "-readonly", "-noidme", "-mountrandom", "/var/folders/4r/ch0_6t6d2pjf0rrwrf9kw2q400bb5y/T/d20171116-91837-acx2kr", "/Users/jbard/Library/Caches/Homebrew/Cask/java--9.0.1,11.dmg"]
==> Executing: ["/usr/bin/find", ".", "-print0"]
==> Executing: ["/usr/bin/mkbom", "-s", "-i", "/var/folders/4r/ch0_6t6d2pjf0rrwrf9kw2q400bb5y/T/20171116-91837-1v3nnq6.list", "--", "/var/folders/4r/ch0_6t6d2pjf0rrwrf9kw2q400bb5y/T/20171116-91837-qfxep3.bom"]
==> Executing: ["/usr/bin/ditto", "--bom", "/var/folders/4r/ch0_6t6d2pjf0rrwrf9kw2q400bb5y/T/20171116-91837-qfxep3.bom", "--", "/private/var/folders/4r/ch0_6t6d2pjf0rrwrf9kw2q400bb5y/T/d20171116-91837-acx2kr/dmg.DmidfV", "/usr/local/Caskroom/java/9.0.1,11"]
==> Executing: ["/usr/sbin/diskutil", "eject", "/private/var/folders/4r/ch0_6t6d2pjf0rrwrf9kw2q400bb5y/T/d20171116-91837-acx2kr/dmg.DmidfV"]
==> Creating metadata directory /usr/local/Caskroom/java/.metadata/9.0.1,11/20171116155747.335.
==> Creating metadata subdirectory /usr/local/Caskroom/java/.metadata/9.0.1,11/20171116155747.335/Casks.
==> Installing artifacts
==> 5 artifact/s defined
#<SortedSet:0x00000105a193d8>
==> Installing artifact of class Hbc::Artifact::PreflightBlock
==> Installing artifact of class Hbc::Artifact::Pkg
==> Running installer for java; your password may be necessary.
==> Package installers may write to any location; options such as --appdir are ignored.
==> Executing: ["/usr/bin/sudo", "-E", "--", "/usr/sbin/installer", "-pkg", "/usr/local/Caskroom/java/9.0.1,11/JDK 9.0.1.pkg", "-target", "/", "-verboseR"]
==> sudo: sorry, you are not allowed to preserve the environment
==> Reverting installation of artifact of class Hbc::Artifact::PreflightBlock
==> Purging files for version 9.0.1,11 of Cask java
Error: Command failed to execute!

==> Failed command:
/usr/bin/sudo -E -- /usr/sbin/installer -pkg /usr/local/Caskroom/java/9.0.1,11/JDK 9.0.1.pkg -target / -verboseR

==> Standard Output of failed command:

==> Standard Error of failed command:
sudo: sorry, you are not allowed to preserve the environment

==> Exit status of failed command:
#<Process::Status: pid 91992 exit 1>

/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/system_command.rb:73:in `assert_success'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/system_command.rb:35:in `run!'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/system_command.rb:13:in `run'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/system_command.rb:17:in `run!'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/artifact/pkg.rb:53:in `block in run_installer'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/artifact/pkg.rb:59:in `with_choices_file'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/artifact/pkg.rb:51:in `run_installer'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/artifact/pkg.rb:32:in `install_phase'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/installer.rb:191:in `block in install_artifacts'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/lib/ruby/2.3.0/set.rb:674:in `each'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/lib/ruby/2.3.0/set.rb:674:in `each'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/installer.rb:183:in `install_artifacts'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/installer.rb:97:in `install'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli/install.rb:19:in `block in run'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli/install.rb:13:in `each'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli/install.rb:13:in `run'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli/abstract_command.rb:35:in `run'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:97:in `run_command'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:167:in `run'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:131:in `run'
/usr/local/Homebrew/Library/Homebrew/cmd/cask.rb:8:in `cask'
/usr/local/Homebrew/Library/Homebrew/brew.rb:100:in `<main>'
Error: Kernel.exit
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:172:in `exit'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:172:in `rescue in run'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:155:in `run'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:131:in `run'
/usr/local/Homebrew/Library/Homebrew/cmd/cask.rb:8:in `cask'
/usr/local/Homebrew/Library/Homebrew/brew.rb:100:in `<main>'
$

Output of brew cask doctor
$ brew cask doctor
==> Homebrew-Cask Version
Homebrew-Cask 1.3.7-4-g2953493
caskroom/homebrew-cask (git revision de23c6; last commit 2017-11-16)
==> Homebrew-Cask Install Location
<NONE>
==> Homebrew-Cask Staging Location
/usr/local/Caskroom
==> Homebrew-Cask Cached Downloads
~/Library/Caches/Homebrew/Cask (1 files, 382.1MB)
==> Homebrew-Cask Taps:
/usr/local/Homebrew/Library/Taps/caskroom/homebrew-cask (3819 casks)
==> Contents of $LOAD_PATH
/usr/local/Homebrew/Library/Homebrew/cask/lib
/usr/local/Homebrew/Library/Homebrew
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/lib/ruby/gems/2.3.0/gems/did_you_mean-1.0.0/lib
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/lib/ruby/site_ruby/2.3.0
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/lib/ruby/site_ruby/2.3.0/x86_64-darwin9.0
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/lib/ruby/site_ruby/2.3.0/universal-darwin9.0
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/lib/ruby/site_ruby
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/lib/ruby/vendor_ruby/2.3.0
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/lib/ruby/vendor_ruby/2.3.0/x86_64-darwin9.0
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/lib/ruby/vendor_ruby/2.3.0/universal-darwin9.0
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/lib/ruby/vendor_ruby
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/lib/ruby/2.3.0
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/lib/ruby/2.3.0/x86_64-darwin9.0
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/lib/ruby/2.3.0/universal-darwin9.0
==> Environment Variables
LANG="en_US.UTF-8"
PATH="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/Wireshark.app/Contents/MacOS:/usr/local/Homebrew/Library/Homebrew/shims/scm"
SHELL="/bin/bash"
$

Additional info
macOS Sierra Version 10.12.6:
$ uname -a
Darwin ***.***.com 16.7.0 Darwin Kernel Version 16.7.0: Wed Oct  4 00:17:00 PDT 2017; root:xnu-3789.71.6~1/RELEASE_X86_64 x86_64
$

Relevant parts of my /private/etc/sudoers:
%admin		ALL = (ALL) ALL
%admin ALL=(root) NOPASSWD: /usr/sbin/installer *
%admin ALL=(root) NOPASSWD: /usr/bin/gem *

Add SETENV
https://superuser.com/questions/636283/how-to-allow-user-to-preserve-environment-with-sudo


Rename ResultExt::to_field_err?

The method name ResultExt::fo_field_err is a bit confusing, since it implies an Err return type.
We could leave it as is, or rename it to to_field_result or to_field_res.
If we rename, it should definitely be before 1.0.
Thoughts, @mhallin ?

Sounds reasonable, but while we're on the topic of field errors... I feel that error handling is a bit unergonomic right now. For example, if you're doing stuff that can fail, you've got two options in practice:

Import juniper::ResultExt, write e.g. let txn = db.transaction().to_field_result()?;
Use jtry!, e.g. let txn = jtry(db.transaction());

Converting error types yourself feels like a shortcoming on Juniper's side; why should a user have to care about that? On the other hand, using the macro looks a bit weird when you're chaining operations that can fail: jtry!(jtry!(File.open(...)).read(...)).
So, I wonder if we could make the macros support any kind of Result<T, E> (or at least E: Display) and call .to_field_result() on the result automatically? Then we could maybe even remove the ResultExt trait and jtry! macro.

IIRC both the try macro as well as the ? operator provide type upcasting: https://github.com/rust-lang/rfcs/blob/master/text/0243-trait-based-exception-handling.md#exception-type-upcasting.
So an alternative could be to define a concrete type FieldError implementing From:
struct FieldError {
  message: String
}

type FieldResult<T> = Result<T, FieldError>;

impl<E> From<E> for FieldError where E: Display {
  fn from(err: E) -> FieldError {
    FieldError { message: err }
  }
}

This would enable people to use the ? operator without to_field_result in field bodies:
field foo()  {
  let txn = db.transaction()?;
  ...
}

Deprecating the macros is something we already talked about.
I'll write more here later, but just for now: https://github.com/graphql-rust/juniper/issues/40 is also relevant for this.

Both ResultExt and the jtry macro were removed in 0.9.


Группировка операций по названию роута

Сейчас по умолчанию SpanName резолвится через path роута. Но лучше использовать имя роута, если оно есть. Таким образом, не будет куча лишних операций.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

3 of 3 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.5%) to 80.603%

Totals

Change from base Build<PHONE_NUMBER>:
0.5%

Covered Lines:
187

Relevant Lines:
232

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

3 of 3 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.5%) to 80.603%

Totals

Change from base Build<PHONE_NUMBER>:
0.5%

Covered Lines:
187

Relevant Lines:
232

💛  - Coveralls


Artifacts in the LiDAR image

Hello,
I have a question regarding the sensor position of LiDAR:
During data generation, I lowered the LiDAR sensor so that the engine hood of the ego-vehicle is almost visible (invisible), meaning the field of view (FOV) of the LiDAR sensor starts just above it. But when using the same sensor configuration and position for evaluation, the engine hood is slightly visible. However, if I raise the sensor by just 2 cm during evaluation, the engine hood becomes invisible again.
I understand that internal processing differs based on the sensor position, but I am referring specifically to a visualization of the raw npy files directly from the sensor. I am aware that two parameters in the LiDAR sensor configuration differ between data generation and evaluation (DATAGEN), but these parameters do not cause this issue. The vehicle type is the same in both settings.
Do you have any idea what could be causing this? Is there a different scaling of vehicles in these two modes or are points from the sensor detected earlier?

Hm, I don't know. I expect the point clouds to be the same if you use the same settings.
The code changes the coordinate system of data at various places, but if you extract the points clouds directly from the CARLA leaderboard there should be no difference if the parameters are set the same.
Some pointers for debugging:
You can check the parameters here.
To get the raw data from the carla leaderboard you need to pick it up here
Docu of the LiDAR sensor .