@ms I came back to this when running release tests with our new release.
The simplest thing you can do is to explicitly disconnect the ctrl object on error:
async function test() {
let ctrl; // move declaration here
try {
const va = typeof window === "object" ?
VisionAppster : // Browser
require("visionappster"); // Node.js
const inputs = [
await va.Image.fromUrl('image.jpg')
];
ctrl = new va.RemoteObject("http://localhost:2015/apis/com.myapps.testapp/1");
const api = await ctrl.connect();
await api.sendImage.async(...inputs);
console.log('Success.');
}
catch {
console.error("Failed.");
ctrl.disconnect(); // add this
}
}
It is hard to do this automatically because JS is a garbage-collected language with no destructors. When the app on the server side is brought down, its control channel remains because no one called disconnect() on the client side. The JS runtime can keep the old instance alive arbitrarily long. Since there is a reference to the WebSocket instance, the connection will remain active as well.
Now, when you create a new RemoteObject instance, it shares an existing connection by default (you are using the default mechanism). This time however the existing connection is defunct. The old server-side object does not exist any more although there is a new one in the same URL.
The channel sharing mechanism could be improved to take the remote object ID into account, but that would be a rather invasive change now. The work-around is quite simple and I hope it will work for you for the time being. We'll come back to this during the next release cycle.
-Topi-
