You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 )
The text was updated successfully, but these errors were encountered:
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.
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.
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 )
The text was updated successfully, but these errors were encountered: