Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate: Classy Integration: TransientError: 400: {"error":{"email_address":["This email address is already used."]}} #162

Open
ometa opened this issue Nov 29, 2022 · 1 comment

Comments

@ometa
Copy link
Member

ometa commented Nov 29, 2022

We think a repro for this case is:

  • Use a team that has successfully registered in dogtag and in classy in the past
  • Change the email address in dogtag
  • Attempt to register for the new race using that team
  • Expect to observe This email address is already used in sidekiq
Workers::ClassyCreateFundraisingTeam
{"team_id"=>1054}
400: {"error":{"email_address":["This email address is already used."]}}
/app/lib/classy_client.rb:164:in `wrapper'
/app/lib/classy_client.rb:137:in `block in post'
/app/lib/classy_client.rb:124:in `with_token'
/app/lib/classy_client.rb:135:in `post'
/app/lib/classy_client.rb:57:in `create_member'
/app/lib/classy_user.rb:34:in `link_user_to_classy!'
/app/app/workers/workers/classy_create_fundraising_team.rb:47:in `run'
/app/app/workers/workers/common.rb:29:in `perform'
/app/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.3.1/lib/sidekiq/processor.rb:196:in `execute_job'
/app/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.3.1/lib/sidekiq/processor.rb:164:in `block (2 levels) in process'
/app/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.3.1/lib/sidekiq/middleware/chain.rb:138:in `block in invoke'
/app/vendor/bundle/ruby/2.7.0/gems/rollbar-3.3.0/lib/rollbar/plugins/sidekiq/plugin.rb:11:in `call'
/app/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.3.1/lib/sidekiq/middleware/chain.rb:140:in `block in invoke'
/app/vendor/bundle/ruby/2.7.0/gems/newrelic_rpm-8.3.0/lib/new_relic/agent/instrumentation/sidekiq.rb:35:in `block in call'
/app/vendor/bundle/ruby/2.7.0/gems/newrelic_rpm-8.3.0/lib/new_relic/agent/instrumentation/controller_instrumentation.rb:377:in `perform_action_with_newrelic_trace'
/app/vendor/bundle/ruby/2.7.0/gems/newrelic_rpm-8.3.0/lib/new_relic/agent/instrumentation/sidekiq.rb:30:in `call'
/app/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.3.1/lib/sidekiq/middleware/chain.rb:140:in `block in invoke'
/app/vendor/bundle/ruby/2.7.0/gems/sidekiq-failures-1.0.1/lib/sidekiq/failures/middleware.rb:9:in `call'
/app/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.3.1/lib/sidekiq/middleware/chain.rb:140:in `block in invoke'
/app/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.3.1/lib/sidekiq/middleware/chain.rb:143:in `invoke'
/app/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.3.1/lib/sidekiq/processor.rb:163:in `block in process'
/app/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.3.1/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
/app/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.3.1/lib/sidekiq/job_retry.rb:112:in `local'
/app/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.3.1/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
/app/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.3.1/lib/sidekiq/rails.rb:14:in `block in call'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-5.0.7.2/lib/active_support/execution_wrapper.rb:85:in `wrap'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-5.0.7.2/lib/active_support/reloader.rb:68:in `block in wrap'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-5.0.7.2/lib/active_support/execution_wrapper.rb:85:in `wrap'
/app/vendor/bundle/ruby/2.7.0/gems/activesupport-5.0.7.2/lib/active_support/reloader.rb:67:in `wrap'
/app/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.3.1/lib/sidekiq/rails.rb:13:in `call'
/app/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.3.1/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
/app/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.3.1/lib/sidekiq/processor.rb:257:in `stats'
/app/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.3.1/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
/app/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.3.1/lib/sidekiq/job_logger.rb:13:in `call'
/app/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.3.1/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
/app/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.3.1/lib/sidekiq/job_retry.rb:79:in `global'
/app/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.3.1/lib/sidekiq/processor.rb:124:in `block in dispatch'
/app/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.3.1/lib/sidekiq/logger.rb:11:in `with'
/app/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.3.1/lib/sidekiq/job_logger.rb:33:in `prepare'
/app/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.3.1/lib/sidekiq/processor.rb:123:in `dispatch'
/app/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.3.1/lib/sidekiq/processor.rb:162:in `process'
/app/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.3.1/lib/sidekiq/processor.rb:78:in `process_one'
/app/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.3.1/lib/sidekiq/processor.rb:68:in `run'
/app/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.3.1/lib/sidekiq/util.rb:43:in `watchdog'
/app/vendor/bundle/ruby/2.7.0/gems/sidekiq-6.3.1/lib/sidekiq/util.rb:52:in `block in safe_thread'
@ometa ometa changed the title Investigate: TransientError: 400: {"error":{"email_address":["This email address is already used."]}} Investigate: Classy Integration: TransientError: 400: {"error":{"email_address":["This email address is already used."]}} Nov 30, 2022
ometa added a commit to ometa/dogtag that referenced this issue Jan 12, 2023
…d. This ensures the email address of the dogtag user is what is used to to request an existing classy id, or to create a classy account. This change fixes the bug if a dogtag user account was used in an earlier race, and there is an existing classy id stored on that user account, and then the dogtag team changes their email address, and then registers for a new race. in this scenario, the code sees the existing classy id and just returns it instead of requesting a classy id (or initiating the new classy account creation) using that newer email address. (chiditarod#162)
ometa added a commit to ometa/dogtag that referenced this issue Jan 12, 2023
…d. This ensures the email address of the dogtag user is what is used to to request an existing classy id, or to create a classy account. This change fixes the bug if a dogtag user account was used in an earlier race, and there is an existing classy id stored on that user account, and then the dogtag team changes their email address, and then registers for a new race. in this scenario, the code sees the existing classy id and just returns it instead of requesting a classy id (or initiating the new classy account creation) using that newer email address. (chiditarod#162)
@ometa
Copy link
Member Author

ometa commented Jan 12, 2023

After further testing there is an issue with the responses returned from the classy api. I've opened a support ticket.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant