Closed azatoth closed 7 years ago
@azatoth could you please provide us with an example code to reproduce the problem? Either a full sandbox per wiki, or even better a failing unit-test in strong-remoting.
Testcase from @azatoth : https://github.com/strongloop/strong-remoting/pull/341
@azatoth I am confused. In your example, your remote method has two "returns" arguments - some sort of data and opts
, but none of them are described in remoting metadata. SharedMethod.prototype.invoke
converts callback ("return") arguments into a single results
object.
Also note that remotingOptions
are coming from server/config.json > remoting
, they are not per-request.
When calling
SharedMethod.prototype.invoke()
the suppliedremotingOptions
are forgotten and this prevents fixes like strongloop/loopback#1495 not working when applied to relations (ModelName/:id/relation
) as the injected remoteCtx is forgotten here.
I don't see how the code in #341 is related to relation endpoints :( I am recommending you to create a full LoopBack application reproducing the issue, see https://github.com/strongloop/loopback/wiki/Reporting-issues#bug-report.
I am closing this issue as we don't have enough information to reproduce it. @azatoth feel free to reopen it if/when you can provide us with complete steps to reproduce the problem.
When calling
SharedMethod.prototype.invoke()
the suppliedremotingOptions
are forgotten and this prevents fixes like https://github.com/strongloop/loopback/issues/1495 not working when applied to relations (ModelName/:id/relation
) as the injectedremoteCtx
is forgotten here. A naïve fix I thought was to just pushremotingOptions
ontoformattedArgs
before the callback, but this sadly breaks most subsequent callbacks.