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

Unhandled: POST /v1/subscriptions containing trial_from_plan #162

Open
lowlyocean opened this issue Dec 1, 2020 · 2 comments
Open

Unhandled: POST /v1/subscriptions containing trial_from_plan #162

lowlyocean opened this issue Dec 1, 2020 · 2 comments

Comments

@lowlyocean
Copy link
Contributor

lowlyocean commented Dec 1, 2020

Parameter here isn't supported (it returns 400 User Error). Defaulting trial_from_plan here causes subsequent 404 here . More generally, is returning 400 User Error whenever some parameter isn't in the method signature really a necessary pattern in this project? If some parameter isn't listed, is there any reasonable way to return a 200 ( or maybe the attempt could be recorded somewhere and help generate/prioritize Github issues based on frequency of that particular parameter being attempted )

@adrienverge
Copy link
Owner

More generally, is returning 400 User Error whenever some parameter isn't in the method signature really a necessary pattern in this project?

It is, localstripe aims to mimic real Stripe servers. However missing parameters are very easy to "just add" (you can find examples in recent commits), i.e. add the parameter but don't use it. It won't solve your 404 problem though, unless it's easy to use the trial_from_plan parameter?

And this is a volunteer-supported project, we don't log or monitor usage from our users.

@lowlyocean
Copy link
Contributor Author

And this is a volunteer-supported project, we don't log or monitor usage from our users.

Especially because it's volunteer-based (and because the real API can be changing rapidly) it would be helpful to have a live dashboard highlighting where most effort should be focused.

It seems these two do not need to be mutually exclusive, though I suppose two obvious questions arise: 1) how to capture usages and create dashboard with list of parameters to add support for? 2) would users be asked to opt-in to such analytics?

Anyway it's OK if it's not in the roadmap, but just something to consider in case someone wishes to fork, etc.

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

2 participants