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.

Sign up for GitHub

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

Jump to bottom

Can not iterate through line items for an upcoming invoice #646

Closed
myfitment opened this issue May 7, 2018 · 0 comments
Closed

Can not iterate through line items for an upcoming invoice #646

myfitment opened this issue May 7, 2018 · 0 comments

Comments

@myfitment
Copy link

NOTE: This issue does NOT occur when iterating through line items for past invoices. It ONLY occurs on upcoming_invoice.

Ruby: 2.3.3p222
Stripe: 3.13.0

Stripe::InvalidRequestError
Missing required param: customer.

Code:

    # Where user.stripe_customer returns the Stripe customer object
    stripe_customer = user.stripe_customer
    stripe_invoice = stripe_customer.upcoming_invoice
    stripe_invoice.lines.all().each do |line_item|
      # do something
    end

The call to:

stripe_invoice.lines.all()

triggers the error.

Backtrace:

/data/myfitment/shared/bundled_gems/ruby/2.3.0/bundler/gems/stripe-ruby-21b0514d1e1e/lib/stripe/stripe_client.rb:277:in `handle_error_response'
/data/myfitment/shared/bundled_gems/ruby/2.3.0/bundler/gems/stripe-ruby-21b0514d1e1e/lib/stripe/stripe_client.rb:228:in `rescue in execute_request_with_rescues'
/data/myfitment/shared/bundled_gems/ruby/2.3.0/bundler/gems/stripe-ruby-21b0514d1e1e/lib/stripe/stripe_client.rb:196:in `execute_request_with_rescues'
/data/myfitment/shared/bundled_gems/ruby/2.3.0/bundler/gems/stripe-ruby-21b0514d1e1e/lib/stripe/stripe_client.rb:152:in `execute_request'
/data/myfitment/shared/bundled_gems/ruby/2.3.0/bundler/gems/stripe-ruby-21b0514d1e1e/lib/stripe/api_operations/request.rb:17:in `request'
/data/myfitment/shared/bundled_gems/ruby/2.3.0/bundler/gems/stripe-ruby-21b0514d1e1e/lib/stripe/api_operations/request.rb:51:in `request'
/data/myfitment/shared/bundled_gems/ruby/2.3.0/bundler/gems/stripe-ruby-21b0514d1e1e/lib/stripe/api_operations/list.rb:7:in `list'
brandur-stripe pushed a commit that referenced this issue May 7, 2018
@brandur
Merge query parameters coming from path with params argument
c57f5c2 
If specifying both query parameters in a path/URL down to Faraday (e.g.,
`/v1/invoices/upcoming?coupon=25OFF`) _and_ query parameters in a hash
(e.g., `{ customer: "cus_123" }`), it will silently overwrite the ones
in the path with the ones in the hash. This can cause problems where
some critical parameters are discarded and causes an error, as seen in
issue #646.

This patch modifies `#execute_request` so that before going out to
Faraday we check whether the incoming path has query parameters. If it
does, we decode them and add them to our `query_params` hash so that
all parameters from either place are preserved.

Fixes #646.
@brandur brandur mentioned this issue May 7, 2018
Merged
brandur-stripe pushed a commit that referenced this issue May 7, 2018
@brandur
Merge query parameters coming from path with params argument
01ec2cd 
If specifying both query parameters in a path/URL down to Faraday (e.g.,
`/v1/invoices/upcoming?coupon=25OFF`) _and_ query parameters in a hash
(e.g., `{ customer: "cus_123" }`), it will silently overwrite the ones
in the path with the ones in the hash. This can cause problems where
some critical parameters are discarded and causes an error, as seen in
issue #646.

This patch modifies `#execute_request` so that before going out to
Faraday we check whether the incoming path has query parameters. If it
does, we decode them and add them to our `query_params` hash so that
all parameters from either place are preserved.

Fixes #646.
brandur-stripe pushed a commit that referenced this issue May 7, 2018
@brandur
Merge query parameters coming from path with params argument
fe21618 
If specifying both query parameters in a path/URL down to Faraday (e.g.,
`/v1/invoices/upcoming?coupon=25OFF`) _and_ query parameters in a hash
(e.g., `{ customer: "cus_123" }`), it will silently overwrite the ones
in the path with the ones in the hash. This can cause problems where
some critical parameters are discarded and causes an error, as seen in
issue #646.

This patch modifies `#execute_request` so that before going out to
Faraday we check whether the incoming path has query parameters. If it
does, we decode them and add them to our `query_params` hash so that
all parameters from either place are preserved.

Fixes #646.
brandur-stripe pushed a commit that referenced this issue May 7, 2018
@brandur
Merge query parameters coming from path with params argument
6024fe3 
If specifying both query parameters in a path/URL down to Faraday (e.g.,
`/v1/invoices/upcoming?coupon=25OFF`) _and_ query parameters in a hash
(e.g., `{ customer: "cus_123" }`), it will silently overwrite the ones
in the path with the ones in the hash. This can cause problems where
some critical parameters are discarded and causes an error, as seen in
issue #646.

This patch modifies `#execute_request` so that before going out to
Faraday we check whether the incoming path has query parameters. If it
does, we decode them and add them to our `query_params` hash so that
all parameters from either place are preserved.

Fixes #646.
brandur-stripe pushed a commit that referenced this issue May 7, 2018
@brandur
Merge query parameters coming from path with params argument
0b41357 
If specifying both query parameters in a path/URL down to Faraday (e.g.,
`/v1/invoices/upcoming?coupon=25OFF`) _and_ query parameters in a hash
(e.g., `{ customer: "cus_123" }`), it will silently overwrite the ones
in the path with the ones in the hash. This can cause problems where
some critical parameters are discarded and causes an error, as seen in
issue #646.

This patch modifies `#execute_request` so that before going out to
Faraday we check whether the incoming path has query parameters. If it
does, we decode them and add them to our `query_params` hash so that
all parameters from either place are preserved.

Fixes #646.
brandur-stripe pushed a commit that referenced this issue May 7, 2018
@brandur
Merge query parameters coming from path with params argument
3a2724b 
If specifying both query parameters in a path/URL down to Faraday (e.g.,
`/v1/invoices/upcoming?coupon=25OFF`) _and_ query parameters in a hash
(e.g., `{ customer: "cus_123" }`), it will silently overwrite the ones
in the path with the ones in the hash. This can cause problems where
some critical parameters are discarded and causes an error, as seen in
issue #646.

This patch modifies `#execute_request` so that before going out to
Faraday we check whether the incoming path has query parameters. If it
does, we decode them and add them to our `query_params` hash so that
all parameters from either place are preserved.

Fixes #646.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
0 participants