Please try to add the client__manyToOne:_id relation field in the dependencies properties in your addField method. It will force the field to be computed after the relation.
If you have an error again, is the error always the same? If it is, you have probably a cycle dependency.
A field needs a computed relation to be computed and the relation needs this same field to be computed 
.
Thanks for the suggestion. I didn’t have a chance to try it out yet, will do a.s.a.p. What do you mean by “Are you already blocked?”?
I wanted to know if the workaround works with your problem.
Hi Alban, sorry for my late reply.
No, unfortunately, this does not solve the problem. I don’t know how it would, since the client-relationship has nothing to do with it.
I do get the same error, always the same Cannot read properties of undefined (reading 'foreignCollection')
There are no cyclic dependencies.
Ty for the feedback.
I’ll get to work on fixing the bug as soon as possible, and then, if the problem persists on your side, we’ll do a pair programming session.
Ok, sounds good, thanks Alban.
@Alban_Bertolini I cleaned all the broken entries in the database, so that all relationships can be established. Unfortunately, the error still persists.
It’s been 21 days and the bug hasn’t been fixed. This is also blocking the release of the new client for us.
The workaround you suggested (with client__manyToOne:_id) does not work. Could you think of another one? For example, adding a relationship to MyCollection in order to make it compute what’s needed?
Or might you have any indication on how long it will take to fix the bug?
Thanks for your efforts - I really appreciate it.
Hello,
The fix is in review, and will be merged today, but maybe you can try it before the merge:
Maybe you will encounter an error again…
The documentation is not ready, but you can add an externalDependencies path in the addField options:
collection.addField('product', {
....
externalDependencies: [{collectionName: 'legalProductOrders_items', path: 'legalProductItem:legalProduct:nameEN'}],
Thanks @Alban_Bertolini, I will try it out as soon as there is an npm version I can point towards. I guess, now, that’s not possible yet. But if it gets merged today, that’s fantastic.
Yes, I can also simply change the version in package.json altogether.
Yet, the thing that blocks me from trying your PR at the moment is that I don’t know which datasource-customizer version to point towards - at least as long as the fix is not released.
Or do you see a way to achieve this?
Yes you can put the agent-nodejs repository with my branch as dependencies. A tutorial: Use Github branch as dependency in package.json | by Jon Church | Medium
Ok, but unfortunately this downloads the source files and not the distribution, so the build breaks on my repository. I saw, that the PR is reviewed, so I’ll wait for it to be merged and released.
Hi @David_Roegiers,
Thanks for the intensive agent test and the related feedback.
This topic is actually very sensitive as a patch would make our API evolve and we want to be collectively sure that it goes in the right direction with intelligible methods or attributes names.
We must take the more time to discuss this and design the best future for the agent on this specific use case.
We understand that you need to deliver value and the only “workaround” we have in mind would be to build a few stuff manually; to retrieve nameEN values manually after the list call, not to use the list method te retrieve the items,… There is no great workaround, but that is the direction you should consider to deliver quickly.
Thanks for you extensive patience.
Hi @arnaud
Thanks for your feedback!
To be honest, after giving it some thought, I am happy, that the solution with externalDependencies is being pulled back. The naming is somewhat confusing. Moreover, from an external point of view, it just makes the addField API complexer without offering value for the consumer. It is redundant with the second argument of the list call, so it merely patches an underlying issue and unnecessarily involves the module user. From the outside perspective, it’s bad design…
That being said, I can imagine, that building a working dependency tree, which correctly prioritizes computed fields and relationships - especially for the pattern I introduced here above (i.e. list call of relationships of a different collection within getValues of a computed field), must be quite a challenge … Is it even possible to fix this “under the hood”?
Anyway, I just implemented the workaround by loading in all the data with separate list requests and then reconstructing the relations. It works for us now. 
Shall we keep this issue open until a fix is released, so I can clean up the workaround in the future? No urgency for me.
Great to read that you are aligned on the fact that we need an elegant patch for this issue, and you have a temporary solution for your use case.
Yes, let’s keep the topic open.
We’ll get back to you and ideally close it once the definitive solution is released and approved on your end.
In another attempt, I tried making a many-to-many relationship between legalProductOrdersand legalProductItems, in order to call that relationship through the dependencies attribute of addField.
This would avoid the need to call a collection list functions with its corresponding relations in the getValues function.
But, I noticed it is not possible to call a many-to-many relationship in a projection. Right? If this can be built in, then there would be no need to solve the scenario I introduced here above.
Hello,
Yes it is not possible to call a many to many in a projection.
