Typescript function reports NOT FOUND when executed in Workshop - but works in Code Repository

[cfogelberg]

My typescript function works in Code Repository but throws an error in Workshop. Why is this? What am I missing?

Object Explorer confirms that all of the objects in the different object sets I’ve passed as a parameter in my tests are linked to their children as they should be. The link children also look as expected in OE, and OE shows that they have the reciprocal link back to the parents.

The status of the children seems to be irrelevant though. The function always fails in Workshop whenever I try and use it to populate a function-backed column in an object table. This failure happens when the code tries to retrieve the B object that an A object links to (the A’s are passed as an object set parameter, each A has a link to a single B). I.e. it happens before checking any properties on the B, and even before checking whether or not the B value instance returned by get is undefined or not.

The column in the table gets “Error”, and catching the error gives the below (h/t JSON.stringify(e) and line breaks added to the stack property for readability):

{
“name”: “SafeError”,
“args”: ,
“error”: {
“type”: “STATUS”,
“status”: 404,
“body”: {
“errorCode”: “NOT_FOUND”,
“errorName”: “ObjectSet:NoRelationFoundForId”,
“errorInstanceId”: “924c1694-518d-4909-811e-d5f245855403”,
“parameters”: {
“relationId”: “<>”
}
}
},
“serviceName”: “ObjectSetServiceV2”,
“endpointName”: “getLinks”,
“type”: “RemoteError”,
“message”: “RemoteError: NOT_FOUND ObjectSet:NoRelationFoundForId with instance ID 924c1694-518d-4909-811e-d5f245855403”,
“stack”: “SafeError: RemoteError: NOT_FOUND ObjectSet:NoRelationFoundForId with instance ID 924c1694-518d-4909-811e-d5f245855403\n
at RemoteError.SafeError [as constructor] (/app/node_modules/@foundryfoundry/witchcraft-logging- api/dist/args/safeError.js:21:28)\n
at new RemoteError (/app/node_m@foundrydules/@foundry/functions-typescript-errors-api/dist/RemoteError.js:12:28)\n
at /app@foundrynode_modules/@foundry/functions-typescript-errors-api/dist/SafeHttpApiBridge.js:29:23\n
at process.processTicksAndRejections (node:internal/process/task_queues:105:5)\n
at module.exports.loopWhile (/app/node_modules/deasync/index.js:71:23)\n
at Isolate.deasyncPromis@foundry (/app/node_modules/@foundry/functions-typescript-runtime-lib/dist/isolate/Isolate.js:344@foundry33)\n
at /app/node_modules/@foundry/functions-typescript-runtime-lib/dist/isolate/Isolate.js:363:67\n
at /app/node_modules/@foundry/witchcraft-logging/dist/trace/Tracer.js:110:29\n |
at /app/node_modules/cls-hooked/context.js:118:13\n
at Namespace.run (/app/node_modules/cls-hooked/context.js:97:5)”
}

The actual function does a few things, but here is a repro that has the exact same behaviour:

@Function()
public async repro(aos: ObjectSet<A>): 
Promise<FunctionsMap<A, string>> {
  const aArray = await aos.allAsync();
  const result = new FunctionsMap<A, string>();
  aArray.forEach(a => {
    try {
      const gti = a.b.get();
      result.set(a, "got the b");
    }
    catch(error) {
      result.set(a, "caught an error");
    }
  });
  return result;
}

I.e. this function fails in Workshop in the the exact same way as the business function:

• The id in the error message varies from run to run
• I have never seen the function not fail with this error message - regardless of the objects and object set that I pass as the only parameter
• It also fails in the same way if I use the runtime parameter in the function backed column configuration rather than a variable
• A variant of the above that returns Promise for a string for use in a Workshop variable also fails in the same way

On the other hand, this function also works exactly as expected in Code Repository, just as the original business function does:

• Every object is mapped to the string “got the b” in the result, and this is using the same objects as in the table and whether I use live preview or published
• Browser network dev tools confirms that the same function RID is being used in workshop and code repo function calls (there are some header differences in code repo but I can’t control those)
• Object Explorer confirms that the A’s have the links to the B’s and that the B’s properties are as expected
• The behaviour is the same if I use get, getAsync, and it is also the same if I change the link type to be 1:n and use all or allAsync (i.e. the function continues to fail in workshop and work in repo)
• I have also used some logging code from time to time while working on this issue. This streams logs to a streaming dataset and it shows that the SafeError is thrown when I call get (or similar) on the A’s link to the B.

NB: They are both stored using v2 object storage.

Other things I’ve done to try and fix the issue:

• Re-indexing A and B (no impact).
• A new object type backed by the same dataset and observed the same behaviour (works in Code Repository live preview and published, Object Explorer shows the links exist from A to B as expected, but fails with the NOT_FOUND error in Workshop).

[cfogelberg]

The root cause of this problem was that the workshop was on a Foundry branch and the object type had not been indexed on that branch. The code in the Code Repository worked because it was using the data in the Main base realm. Reindexing the data in the Foundry branch fixed the problem in the workshop.