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 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.
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 withingetValues 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.