dcavanagh
commented
6 years ago @kbirger I'm having some trouble reproducing the error in the test code. Can you please take a look at the test case below? How were you able to produce the 404?
it("should support inherited methods", (done) => {
let container = new Container();
@controller("/api/test")
class BaseController {
@httpGet("/public-things")
public getPublicThings() {
return { things: ["a", "b"] };
}
}
@controller("/api/test")
class TestController extends BaseController {
constructor(/* deps */) {
super(/* deps */);
}
@httpGet("/private-things")
public getPrivateThings() {
return { things: ["c", "d"] };
}
}
let server = new InversifyExpressServer(container);
let app = server.build();
supertest(app).get("/api/test/public-things")
.expect("Content-Type", /json/)
.expect(200)
.then(response1 => {
expect(response1.body.things[0]).to.equal("a");
});
supertest(app).get("/api/test/private-things")
.expect("Content-Type", /json/)
.expect(200)
.then(response1 => {
expect(response1.body.things[0]).to.equal("c");
done();
});
});
kbirger
remojansen
justintime4tea
With the way that https://github.com/inversify/InversifyJS/issues/586 has been fixed, it has broken another use case in a very strange way. Prior to this, I was able to have a non abstract base controller, and another controller that extended its functionality by adding an additional endpoint. The desired effect is that the second controller has all of the endpoints of the first, plus additional ones. As of 5.2.2/6.0.0, this still works, but certain requests described below can crash the server.
As a side note, in the previous version, I had to override all of the base class methods and re-decorate them. I no longer have to do this due to the switch to
getMetadata.This works in the happy path. However, if I
GET /stuff/private-things, it crashes the server. I suppose as a workaround I could implement this case differently, and have an abstract base, etc. But this seems like a natural way to do it, and we probably don't want bugs that can crash the server.Expected Behavior
GET /stuff/private-thingsshould return a 404 as per default behavior.Current Behavior
GET /stuff/private-thingscrashes the serverPossible Solution
I'll have a deeper look at this. It seems like the metadata indicates that a controller method should exist on the base controller, but it actually doesn't. Perhaps all we need is a null check on the controller method to make sure it's really there.
Steps to Reproduce (for bugs)
GET /stuff/private-thingsContext
To have a second controller has all of the endpoints of the first, plus additional ones.
Your Environment
Stack trace
That seems to map to the
handlerFactorymethod in server.ts, though I need to dig deeper into this stack since it's showing me the transpiled JS.I assume it is the line that reads:
let result = childContainer.getNamed<any>(TYPE.Controller, controllerName)[key](...args);