@Cerbrus (FIRE) I've got the basics working, but I'm still testing. I should be submitting a PR in the near future. There are some significant differences in the API and some areas in 2.0 appear broken (or, at least, not as I expect from the documentation). To get things to work, I've had to use a mix of both the 1.0 and 2.0 APIs.
The changes for 2.0 broke things for FIRE's use of 1.0, so changes have been required. j-f1 has made some changes, but not sufficient to get it working.
TBH, I haven't touched FIRE in quite some time. And I really don't have the time to, either... But if you can get it working again, I'd be happy to merge it.
@Cerbrus Without delving into the API 2.0 code, what I'll have will be something I consider a hack, but at least basically functional (i.e. displays the post and you can submit feedback). There are some less critical things which don't appear to be working (e.g. showing you that you already gave feedback), but ... I'm assuming basic functionality soon is more important.
@Cerbrus I agree. V1 was changed such that using filters is required instead of optional. The page which used to permit generating filters, now only produces them for V2.0. Or at least that's what my impression was.
@Cerbrus In the API, perhaps. However, the data the V2.0 API provides is somewhat different than what V1 provides (e.g. feedbacks aren't included with the data supplied with the post, or at least the filter page doesn't give you the option to include them). Further, some of the V2.0 API endpoints appear broken (e.g. creating feedback).
I really should look at the API2.0 code to see what's going on, but I haven't do so yet.
$ cp ../eslint/** ./node_modules/eslint/
Failed to execute process '/bin/cp'. Reason:
The total size of the argument and environment lists 1.7MB exceeds the operating system limit of 256kB.
Try running the command again with fewer arguments.
The limit for the length of a command line is not imposed by the shell, but by the operating system. This limit is usually in the range of hundred kilobytes. POSIX denotes this limit ARG_MAX and on POSIX conformant systems you can query it with
$ getconf ARG_MAX # Get argument limit in bytes
...
@JF @Makyen you can still generate V1 filters manually, with a clone of the MS repo: Filterator::V1.string_from_fields(['api_keys.id', 'api_keys.app_name'])
@ArtOfCode Thanks for the info. I hadn't wanted to get that deep into this at this time. For the portions of V2.0 that are working as expected, it's easier to just switch. BTW: Do you want things that are not working as I would expect in V2.0 reported here, or as issues on GitHub? It's unclear to me if all of them are bugs, just my not understanding what's implied in the documentation, or if the operation is as expected (e.g. not including feedbacks & flags in posts).
@Makyen Expected: not including feedback and flags in posts. I'm conflicted on that one, and there are some technical hurdles involved anyway. At the moment, you can get the data for them from other routes. Pitfall: lists are comma separated in V2, not semicolon separated. Not expected, i.e. bug: most other things going wrong. 500s should definitely not be happening if you've got all the input right.
Worth giving me a ping here before reporting to GH, just in case there's a pitfall I haven't remembered to tell everyone about
@ArtOfCode It looked like not including feedbacks/flags in posts was expected operation. When there's a chance, it'd be nice to update the docs to show what's available (in addition to having fields specified in the filter). It'd also be nice to state that using a filter which includes things a particular request can't generate will result in an error (e.g. with the SE API as a model, it's unclear if adding the filters for other fields (e.g. feedbacks) results in them being included in posts).
@Cerbrus No need for you to apologize. I'm the one who should apologize. While I intended to primarily match the style, I completely failed to check for what was being used for verification in the project, and use it. All of those are things which should always be done. When contributing to a project, one should always try to match the style already in use. When contributing to multiple projects, this often means using styles which are not one's "natural" style. My fault. Sorry about that.
@ArtOfCode Possible API V2.0 issue: posting feedback: I had expected to be able use ...api/v2.0/feedbacks/post/[postId]/create as a drop-in replacement for the V1: ...api/w/post/[postId]/feedback, but I get a 500/Internal server error: {"name":"persistence_fail","detail":"Feedback object failed to save."}.
@ArtOfCode Done. Hmmm... Looks like I get two different responses. The one I mentioned above and an HTML document titled "Action Controller: Exception caught".
@ArtOfCode Hmmm... If you want to generate them yourself, in FIRE change ${ms.urlV1}w/post/${data.id}/feedback to ${ms.url}feedbacks/post/${data.id}/create.
@Makyen repro and partial explanation: you already have feedback on 98105 and 98106, so the persistence_fail error is expected: you can't feed back twice. Could have a better error message, though.
The exception caught page is not expected, but I can't repro it
@ArtOfCode OK. Let me find one where I don't yet have feedback. I had initially tried this on ones where I didn't have feedback. It failed with a similar error (I'm recalling it was the HTML page, but let me see if I can duplicate).
@ArtOfCode I just tried it on a report, 98096, which I did not previously have feedback. I got the "Action Controller: Exception caught" error, but the feedback was recorded.
The limit for the length of a command line is not imposed by the shell, but by the operating system. This limit is usually in the range of hundred kilobytes. POSIX denotes this limit ARG_MAX and on POSIX conformant systems you can query it with
$ getconf ARG_MAX # Get argument limit in bytes
...
