Ive got a bit of a head scratcher here and I am not ruling out a NS bug. I've got a script that transforms a work order into a work order issue (dynamic mode is true as I need values that I dont want to calculate). It then sets inventory detail values as you normally would through the inventorydetail->inventoryassignment. I can do exactly what I want in the UI by going to a Work Order and clicking the native issue button. The script version sometimes works and sometimes gives an error on save only that inventory detail needs to be configured for the line even though it has been. Even a Work Order that previously worked and is copied fails on save. Is there something you have to special for these transforms? This can't be code related as I've set inventory detail like this tons of times. Just looking for potential pitfalls functionally.

wonder if it could be some other script/workflow executing on save? I tend to be suspicious when the same code in my script appears to behave erratically with near identical use cases.

This is a RESTlet sorry I didn't make that clear. On save in this case is on save of the work order issue record. Everything goes fine until save.

I haven't used 'work order issue' records, but AFAIK when a restlet saves a record it's still subject to other script types and workflows running

No other scripts/workflows interfering which thickens the plot. I'm leaning towards it being SOMETHING with dynamic mode (as usual)

do they ever figure it out?

They do sometimes. Just depends on who you get.

well best of luck to thee.

@creece I've had success in the past by wrapping the save in a try catch, and simply retry the save over and over (max 5 times in most cases). If the 5th fails, then I let the exception bubble up

omg that sounds scary

why?

Probably because you're doing the same action 5 times in a row. Seems a bit weird to "hammer" it like that.

Well, with all the 'unexpected' errors returned, its like opening a stuck drawer sometimes ... keep pulling on it until its gets unstuck

ha yeah I hear ya

Yes, saving 5 times in a row expecting different outcome is kinda wacky. Even more so if you actually observe a different outcome after saving the exact same object 5 times. I'm the type to try and resolve the root cause rather than just assume I have to keep pulling on the drawer 🙂 I'm lazy and would rather fix the drawer once than pull on it forever.

@stalbert, to be clear ... I'm not saying to shove the round peg into the square hole. I'm saying, if you've done the job right ... its works 90% time, and the other 10% is the classic 'unexpected error' ... then a retry isn't out of the question.

aye, the totally useless 'unexpected error' doesn't give one much to go on. The sad thing is that if retries solve it it suggests there is some sort of race condition or other insidious concurrency problem - which indeed may not even be something accessible as SuiteScript devs.