Currently, the agreements connection should be used with regular queries.
Implementing Node on sales agreements is a request on our radar. I can definitely see how that would be useful and needed within bulk operations.
99% of my queries don’t need pagination on agreements & work fine, it’s a pity to give up bulk queries just for a tiny fraction of queries. Can there at least be a more specific error when this fails? If no pagination is needed then great, but if yes return an errorCode “non-node connection needs pagination”, at least in this case I’ll know what the issue is. (or perhaps add a errorDescription field and put it there? )
The ideal state would be to have Node implemented so this would be a supported field for bulk operations. I can pass that suggestion on to add a descriptive error in the meantime though.
Since 99% of your queries are working, would it work to implement a fallback behavior on internal server errors to run a subset of the request as a standard API query?
I realize that shouldn’t be necessary, but something like that could be more resilient for a variety of errors, not just this specific one.
Any additional context to the impact to business these kinds of errors cause will personally help me better understand the roadblocks as I help support others, but I can also ensure I’m properly communicating with our internal developers to ensure fixes and features are prioritized properly.
Issue is that for internal server errors I have coded a retry. After a few retries I go to fallback. If I would have a more descriptive error, I would go straight to fallback without any retries.