I'm not sure that is the issue. I'll have a further look from the NodeJS side and see what is happening.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 17 2014
Ok, I managed to grab some of the data that is causing the 400:
This may be a wider issue with Remarkup... I'm not too sure.
Jul 16 2014
Oh wow... I have literally never noticed this. Thanks
With .arclint, this inconsistency is hidden from the API, in that there is only one engine, and it's implicit; In theory, the word "engine" isn't used in the lint flow any more.
By analogy, a ConfigurationDrivenUnit<something> would not be exposed, and the .arcunit file will hold test "engines" in the current meaning ("uniter"? "runner"? "tester"?).
I guess I'm suggesting is to make the lint code be more like the unit code (By removing the Engine layer from it). This will still break stuff, but mostly stuff we were trying to get rid of anyway, instead of just rename.
What's that exactly?
I think that Aphront should probably be in it's own module, rather than being added to libphutil. Celerity would also be in that module.
I can see at some point in the far future phutil being used as a module and package system for building sites or command line tools (which only need libphutil and don't want a full web stack).
In T1806#11, @epriestley wrote:For example, require_celerity_resource() and javelin_tag() are defined in Phabricator, but a lot of the moved code depends on them (I'm surprised arc lint didn't complain about this).
Thanks for the feedback. I figured that it was probably-not-quite-right but wasn't sure how to tackle this exactly (you're feedback now provides a better understanding of the work involved.
I've attached two diffs (D9941 and D9942) which I think close this task, although it seemed too simple? Let me know if anything is missing.
Jul 15 2014
Jul 14 2014
Jul 13 2014
Ah whoops, yeah you're right.
Sure, sounds reasonable and it seems that T4420 isnt far away from being resolved (fixed in D9903).
Jul 11 2014
I guess I'm primarily talking about maniphest. You (@epriestley) commented on two tickets (T5604 and T5602) and I had two notifications: one update subscribers and one commented.
Yeah that all sounds reasonable.
I suppose that differentials has a stronger case than maniphests. As in, there are some projects which don't make any sense to be specified as code reviewers.
Being a member of Blessed Reviewers doesnt imply that you can add new members. We have an "Access" project for this purpose.
Closed by commit rP9a679bf3746c.
Jul 10 2014
I guess maybe that would get us half-way there. As in, it would allow us to say that upgrading might solve the problem, whereas a Conduit call could allow us to say whether upgrading would solve the problem. Just not sure if its worth the effort.
Actually, if this seems reasonable then I should be able to work on it.
I think that this is related (but possibly not). If I navigate to Diffusion > A repository > A commit and then hit the back button, I get this:
I'll just leave it as is.
(Does it make more sense for a lower number to represent a higher priority?)