search

stripe / openapi

An OpenAPI specification for the Stripe API.
MIT License
394 stars 123 forks source link

swagger-codegen fails #5

Closed wzph closed 7 years ago

wzph commented 7 years ago

Should swagger-codegen succeed in building spec2.json or spec2.yaml? I am getting the following:


  Tag: default
  Operation: Create3DSecure
  Resource: post /v1/3d_secure
  Definitions: {account=io.swagger.models.ModelImpl@18b21fca, account_debit_account=io.swagger.models.ModelImpl@3372b161, account_decline_charge_on=io.swagger.models.ModelImpl@b29ecc58, account_tos_acceptance=io.swagger.models.ModelImpl@11eeb12e, account_verification=io.swagger.models.ModelImpl@4e23beef, account_with_keys=io.swagger.models.ModelImpl@5a54cb3a, address=io.swagger.models.ModelImpl@a5eb90b2, alipay_account=io.swagger.models.ModelImpl@f5050f17, apple_pay_domain=io.swagger.models.ModelImpl@827c2072, application=io.swagger.models.ModelImpl@a048ba69, authorization=io.swagger.models.ModelImpl@88dcae6, backwards_compatible_platform_earning=io.swagger.models.ModelImpl@87a58727, balance=io.swagger.models.ModelImpl@799013db, balance_transaction=io.swagger.models.ModelImpl@afbbfe67, bank_account=io.swagger.models.ModelImpl@2adef309, bitcoin_receiver=io.swagger.models.ModelImpl@9d641c16, bitcoin_transaction=io.swagger.models.ModelImpl@cf233639, card=io.swagger.models.ModelImpl@bcd5b9e3, charge=io.swagger.models.ModelImpl@7f4792b5, charge_outcome=io.swagger.models.ModelImpl@3b18fe54, country_spec=io.swagger.models.ModelImpl@d4343175, coupon=io.swagger.models.ModelImpl@87ee77eb, customer=io.swagger.models.ModelImpl@a4417221, customer_shipping=io.swagger.models.ModelImpl@b5d1d50c, customer_source=io.swagger.models.ModelImpl@8e26206, delivery_estimate=io.swagger.models.ModelImpl@121256f6, discount=io.swagger.models.ModelImpl@722c9a8a, dispute=io.swagger.models.ModelImpl@846f0633, event=io.swagger.models.ModelImpl@21086177, event_data=io.swagger.models.ModelImpl@fcc02ad, external_account_source=io.swagger.models.ModelImpl@e885132e, fee=io.swagger.models.ModelImpl@4feaea84, fee_refund=io.swagger.models.ModelImpl@83d5709d, file=io.swagger.models.ModelImpl@9c2ca4c, inventory=io.swagger.models.ModelImpl@4aa15b61, invoice=io.swagger.models.ModelImpl@4930db3d, invoice_item=io.swagger.models.ModelImpl@dc109079, invoice_line_item=io.swagger.models.ModelImpl@9d856f83, issued_card=io.swagger.models.ModelImpl@61150390, legacy_transfer=io.swagger.models.ModelImpl@b1da5b97, legal_entity=io.swagger.models.ModelImpl@8f70d302, legal_entity_additional_owner=io.swagger.models.ModelImpl@31cd3acf, legal_entity_address=io.swagger.models.ModelImpl@fa79e15c, legal_entity_dob=io.swagger.models.ModelImpl@f0c5b8fd, legal_entity_japan_address=io.swagger.models.ModelImpl@6e015581, legal_entity_verification=io.swagger.models.ModelImpl@b3041dc7, login_link=io.swagger.models.ModelImpl@304aefd7, merchant_data=io.swagger.models.ModelImpl@6042bb20, order=io.swagger.models.ModelImpl@4d3772b4, order_item=io.swagger.models.ModelImpl@8263655d, order_return=io.swagger.models.ModelImpl@438af2f9, package_dimensions=io.swagger.models.ModelImpl@760132f6, payout=io.swagger.models.ModelImpl@2a43a262, plan=io.swagger.models.ModelImpl@904497e6, platform_earning=io.swagger.models.ModelImpl@7aede5eb, platform_fee=io.swagger.models.ModelImpl@3c10bde7, product=io.swagger.models.ModelImpl@66ebb904, refund=io.swagger.models.ModelImpl@8dac76f6, reserve_transaction=io.swagger.models.ModelImpl@917c8d39, review=io.swagger.models.ModelImpl@b436ee78, rule=io.swagger.models.ModelImpl@a36beb49, shipping=io.swagger.models.ModelImpl@c19d562d, shipping_method=io.swagger.models.ModelImpl@bb79e1f6, sku=io.swagger.models.ModelImpl@2aa70ebf, source=io.swagger.models.ModelImpl@9311b156, source_code_verification_flow=io.swagger.models.ModelImpl@ab39138c, source_owner=io.swagger.models.ModelImpl@2d948b54, source_receiver_flow=io.swagger.models.ModelImpl@9a93e4c2, source_redirect_flow=io.swagger.models.ModelImpl@5d89d06d, status_transitions=io.swagger.models.ModelImpl@50a24d, subscription=io.swagger.models.ModelImpl@9dd7f78, subscription_item=io.swagger.models.ModelImpl@f57570c2, three_d_secure=io.swagger.models.ModelImpl@a03bc70e, token=io.swagger.models.ModelImpl@e9c7d270, token_bank_account=io.swagger.models.ModelImpl@5dd6cf3c, token_card=io.swagger.models.ModelImpl@d1ec5ab, transaction=io.swagger.models.ModelImpl@f04bf896, transfer=io.swagger.models.ModelImpl@c8c86292, transfer_recipient=io.swagger.models.ModelImpl@9ad48c12, transfer_recipient_transfer=io.swagger.models.ModelImpl@656a9b, transfer_reversal=io.swagger.models.ModelImpl@f19ae4b0, transfer_schedule=io.swagger.models.ModelImpl@bde15914, upcoming_invoice=io.swagger.models.ModelImpl@237da7e9}
  Exception: null
    at io.swagger.codegen.DefaultGenerator.processOperation(DefaultGenerator.java:861)
    at io.swagger.codegen.DefaultGenerator.processPaths(DefaultGenerator.java:764)
    at io.swagger.codegen.DefaultGenerator.generateApis(DefaultGenerator.java:388)
    at io.swagger.codegen.DefaultGenerator.generate(DefaultGenerator.java:700)
    at io.swagger.codegen.cmd.Generate.run(Generate.java:241)
    at io.swagger.codegen.SwaggerCodegen.main(SwaggerCodegen.java:43)
Caused by: java.lang.NullPointerException
    at io.swagger.codegen.DefaultCodegen.isDataTypeBinary(DefaultCodegen.java:2644)
    at io.swagger.codegen.DefaultCodegen.fromParameter(DefaultCodegen.java:2595)
    at io.swagger.codegen.DefaultCodegen.fromOperation(DefaultCodegen.java:2170)
    at io.swagger.codegen.DefaultGenerator.processOperation(DefaultGenerator.java:808)
    ... 5 more```
brandur-stripe commented 7 years ago

@wzph So I've never explicitly tested against that, but our spec does check out against the OpenAPI 2.0 JSON schema that the project publishes, so I think that it should be roughly valid.

Do you have any idea on what particular quirk is causing the Swagger failure? This smells a little like a swagger-codegen problem, but I'm happy to make a couple tweaks to how we're generating this file if that would help.

wzph commented 7 years ago

So this may not help much, but it's more info. I ran a bunch of other specs (github, azure, aws, google) through swagger-codegen, and they were processed with similar warnings but no errors.

The following complains about definitions[**][type] being an array instead of a string, but changing to a string did not fix the failure in swagger-codegen.

curl -X POST -d @spec2.json -H 'Content-Type:application/json' http://online.swagger.io/validator/debug
brandur-stripe commented 7 years ago

Thanks for the new info!

The following complains about definitions[**][type] being an array instead of a string, but changing to a string did not fix the failure in swagger-codegen.

Hm, interesting. This is something that I could change relatively easily, but I guess it doesn't really seem to be a fix for the problem.

So given that I don't think we're going to be using the Swagger toolchain anytime soon, I'm probably not going to dig into this too deeply right now (I'm sure our formatting isn't quite to its liking, but given that the schema seems to be valid, it seems more like a bug in the generator). However, I'm happy to make any particular fixes to the schema that look like they might be causing the problem if more information becomes available.

wzph commented 7 years ago

Thanks, @brandur-stripe. I agree that making type a scalar isn't going to do much for my issue.

I don't think we're going to be using the Swagger toolchain anytime soon

Does that mean you are using/supporting a different codegen tool?

brandur-stripe commented 7 years ago

Does that mean you are using/supporting a different codegen tool?

I'm interested in doing so, but for now we're using the spec for much more modest uses, like running mock servers that we can hit with our library test suites so that we can move them off doing slow/brittle live API calls. The idea right now though is that we keeping moving forward to more sophisticated uses from there.

joshsmith commented 7 years ago

@brandur-stripe can you clarify what you mean by this?

like running mock servers that we can hit with our library test suites so that we can move them off doing slow/brittle live API calls

We think it's possible in our own Elixir Stripe library to do something similar using this spec, but I'm fuzzy on the details.

brandur-stripe commented 7 years ago

@JoshSmith You can see the details as we're currently implementing them in stripe-ruby here. Basically we spin up a project called Committee and have it ingest the specification into a Sinatra app, then use webmock to redirect requests to api.stripe.com to the fake.

This works pretty well and all of stripe-ruby is powered off of this right. One problem though is that it's not language agnostic, and currently only works in Ruby.

One thing I'm playing with right now is the idea of shipping a small Go executable that does something similar, but which can then be activated in CI environments. Real HTTP requests are sent against it, but it responds 3-4 orders of magnitude faster than if you were really going across the wire.

I call this stripestub, and you can see an example of one of our stripe-java suites running against it in Travis here. This is still an early experiment and I can't guarantee official support for it yet, but I'm collecting feedback internally right now and would like to eventually ship stripestub as an officially supported development tool.

brandur-stripe commented 7 years ago

Going to close this in favor of #10 because it seems that they may have tracked down the issue.