Adds logging support for stripe-ruby in a similar way that we did it for
stripe-python [1], with the idea that users you can optionally get some
additional low-cost-to-configure logging for operational visibility or
debugging.
I made a few tweaks from the Python implementation (which I'll try to
contribute back to there):
* Added an elapsed parameter to responses so you can tell how long they
lasted.
* Mixed in idempotency_key to all lines that users have a way to
aggregate logs related to a request from start to finish.
* Standardized naming between different log lines as much as possible.
* Detect a TTY and produce output that's colorized and formatted.
[1] https://github.com/stripe/stripe-python/pull/269
Moves away from Committee and towards stripe-mock, an external
self-contained executable API stub server based on OpenAPI [1]. The
motivation here is that instead of making stripe-ruby a special
snowflake, we can use a single well-tested and feature-rich mock
implementation to drive every API's test suite.
[1] https://github.com/stripe/stripe-mock
Currently, with a normal API resource, you can unset fields by
specifying a `nil` to that field's setter:
``` ruby
c = Charge.retrieve('ch_123')
c.customer = nil
c.save
```
This actually gets serialized as the form `customer=` (i.e. an empty
string), but we had to use the empty string to handle unsets because
form encoding has no concept of a `nil`/`null`.
To try and prevent usage errors, we actually prevent you from setting
fields with an empty string:
``` ruby
c = Charge.retrieve('ch_123')
c.customer = '' # error! use nil instead
```
When specifying parameters though, this doesn't work anywhere nearly as
well because usage patterns like this are very common in Ruby:
``` ruby
charge_opts = {
params[:amount],
params[:currency],
params[:customer],
}
charge = Charge.create(charge_opts)
```
Each one of `params` above may or may not be `nil`, so we've
traditionally filtered those fields out during the invocation of
`Charge.create`.
Recently, I suggested to Slava that we may be able to change this
behavior, and we ended up putting in a patch as part of #557. Users
brought to my attention that this would be far too disruptive of a
change in #560 though, and having thought about it more carefully, I
agree. There's also an argument that filtered `nil` values are just a
better API, especially in Ruby where patterns like the one above are
frequently in effect.
So the best thing I can think of currently is to leave things as they
were before #557, and just require that users use an explicit empty
string when passes in parameter hashes:
``` ruby
Charge.update(customer: '') # will try to unset customer
```
Empty strings will continue to error for `StripeObject` fields like they
always have.
I don't think this is a perfect solution by any means (the different
between values on `StripeObject` versus using parameters is weird), but
it's the least disruptive thing that I can think of right now that gets
us the functionality that we need for endpoints like
`/v1/invoices/upcoming`.
Fixes#560.
It was brought up in #562 that in case we receive an OAuth error that we
don't know about, `specific_oauth_error` will fall through with a `nil`,
then picked up by `specific_api_error` which will always try to handle
the error as if it were a `Hash` (even if we know it's not!) and thus
lead to typing problems at runtime.
This patch throws a generic `OAuthError` in cases where a code comes
back that we don't recognize. I'm still crazy about the fact that we
don't have a better way of recognizing an OAuth error in particular, but
it should do the trick.
An error in OAuth deauthorization could return the error code of
`invalid_client`, but that isn't handled by the code. That leads to a
`TypeError` instead of a clean, understandable error.
Tweaks the serialization behavior so that when a resource is explicitly
set to a resource's field and that resource is subsequently saved, then
if it looks like the set resource was persisted we extract its ID and
send it up to the API.
By slight extension we also throw an `ArgumentError` if it looks like
that set resource was _not_ persisted because if the user set it
explicitly then it was probably not their intention to have it silently
ignored by the library in the event of a problem.
Redefining the constant like this produces a warning:
```
$ bundle exec rake
/Users/brandur/stripe/stripe-ruby/test/stripe/ephemeral_key_test.rb:75: warning: already initialized constant Stripe::EphemeralKeyTest::FIXTURE
/Users/brandur/stripe/stripe-ruby/test/stripe/ephemeral_key_test.rb:6: warning: previous definition of FIXTURE was here
Loaded suite /Users/brandur/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/rake-11.1.2/lib/rake/rake_test_loader
Started
...
```
They also don't appear to be used, so it should be fine just to strip
them out of the test suite.
This doesn't come back directly from the API so the suite is empty, but
just for completeness add a test file for the newly created
`InvoiceLineItem` model.
Adds support for "app info" (a mechanism that allows a plugin's author
to identify that plugin) in Ruby. This is already supported in PHP and
we're adding it elsewhere.
Previously, the value of whatever accessor was missing was left out of
the call to build it. This had the effect of skipping over the
lazily-built predicate method when the missing accessor is for a
boolean.
Of course, I realize this all is a bit contrived as most of the time
folks aren't assigning these values manually to stripe objects. However,
in my testing it caught me by surprised that the behavior is asymmetric
depending on how and when values are assigned.
As such I believe this is a less surprising implementation.
The Transfer object used to represent all movements of funds in Stripe. It
split in three resources:
- Transfer: this describes the movement of funds between Stripe accounts
and is specific to Stripe Connect.
- Payout: this describes the movement of funds from a Stripe account to a
bank account, debit card or any future payout method.
- RecipientTransfer: this describes the movement of funds from a Stripe
account to a Recipient's card or Bank Account. This is here for legacy
reasons and can only be accessed from an expanded BalanceTransaction.
This change is behind an API version so old API versions would still use
the Transfer object for everything while new API version would see the
split.
This applies beyond the new object as some properties/methods are removed
from Transfer and other properties are renamed on other objects.
See [1] for details, but a few conventions changed around the structure
of the OpenAPI repository and the data within the fixtures file. Here we
put in some minor changes to compensate for them.
[1] https://github.com/stripe/openapi/pull/3
The Faraday::Response object does not respond to #code. The correct
message is #status. It seems this case was previously unhandled by the
test suite as there was no case for the server responding "success" with
an invalid JSON body.
Naming a directory `spec` in a Ruby project is terribly ambiguous. This
clarifies the purpose of this directory and makes it easier to find if
you know that you're looking for OpenAPI.
As described in #506, file uploads were broken on the way over to
Faraday and unfortunately I didn't catch it because the file upload
creation test wasn't using a matcher that was strict enough to really
catch anything.
Here we add the multipart middleware to our Faraday connection, add a
compatibility layer to `FileUpload` so that we can support `File` like
the rest-client based version always did (Faraday generally expects an
`UploadIO` object), and then tighten up our tests so that we'd be able
to catch future regressions.
Fixes#506.
I'd originally added this class for the first stub pass that used
OpenAPI because I thought we'd need the ability to finetune some of our
stubbed responses. It turns out that we've been able to get away without
it so far so I'm removing it for now. This commit can be reverted if it
turns out that we need it back later.
Now that we're powering all test suites with the fixture data that's
generated along with the OpenAPI spec, we don't need this secondary
sample data anymore. Remove all of it except for helpers to simulate
different types of error responses.
Follows the path established in 2d75c8f by porting the rest of
stripe-ruby's tests over to OpenAPI. There are a few other changes here
where I've removed some tests that are duplicated or don't make much
sense, or reorganized how we test certain things, but this commit is
largely the same migration operation applied in bulk a few dozen test
suites.
Ports the charge test suite over to use the stub server which is powered
by the OpenAPI spec and its fixtures.
We also introduce a number of conventions here especially around test
case naming and assertions that we'll diffuse to all other test suites
as we port them over. The entire set of tests is internally inconsistent
because of how each new module and resource was added incrementally over
time and while no strong conventions existed.
Adds some testing infrastructure that reads in the OpenAPI spec and its
fixtures. These changes will allow us to starting porting over each of
stripe-ruby's test suites.
