https://netsuiteprofessionals.com logo
Join Slack
Powered by
Hi friends. I'm still having this issue with recor...
# suitescript
a
Hi friends. I'm still having this issue with record volumes in a Mass/Reduce script. I have a custom function which gets all N/search results, not unlike SuiteAnswer id.86166 (updated 5/22/2020). I use this function in a Suitelet, and it gets north of 9K lines. When I use the same function in getInputData in a Mass/Reduce, the run() passes, but it errors on the first getRange() as UNEXPECTED_ERROR. The columns and filters are exactly the same in both cases. I converted to a version of that is runPaged(), Suite Answer id.79782 (updated 5/22/2020). This continues to work without a problem in the Suitelet, but in the M/R it works for up to 4092 results... but if there are 4093 or more, UNEXPECTED_ERROR at runPaged(). Is there any explanation for this very odd breaking point? Why would it work in a Suitelet but not the M/R? Please help. 😞
.... it's not a governance issue.
s
Why are you using a function to run the search instead of letting the getInput run the search?
a
That's a great question. Because after I get the results, I need to make sure they get numbered in a completely correct, sequential, and procedural order before passing the results to map. I cannot number them in map, because multiple entries get mapped concurrently, and the numbering is out of order, duplicated, or just downright wrong.
Map/Reduce is amazing... but it is problematic if you absolutely need the results sequentially.
I cannot rely on using the dataCache to track the numbering in map either, for exactly the same reason.
s
Why are you using a map/reduce at all, just use a scheduled script and process them in the order they are in the search results
I also don't have any clue why the issue you seem to be having would occur in getInput regardless
a
Me neither. That's why I'm asking.
I need it to be M/R because it's more performant. The scheduled script does not have the governance to handle batches this large. It would require self-rescheduling to be able to perform the number of iterations required. The reduce step saves a file for each record (20 points). The summary step takes the individual files and combines them into stacks of 500 files each. Then it schedules another M/R to delete the singletons.
Scheduled Script = 10K points, start to finish. M/R has separate point allocations per iteration of the entry points.
I mean if I can't get around this very strange bug, I guess I might have to have a SS to number the records first and use that as sorting criteria for the M/R. But the SA id. indicates that I can use .getPaged() in a M/R... so why shouldn't I?
s
I've used countless MR's and never encountered what you are experiencing, makes me believe its not a bug and something else going on with your function that runs the search.
a
But then I run into the same problem with having to self-schedule. SubmitFields() for a transaction is 10 points... so that's max 1K records per Scheduled Script.
Same here. It's why I'm asking. I've never seen it happen before.
What's going on is runPaged() is UNEXPECTED_ERROR 🤷
But only in the M/R -- never the Suitelet -- and only if there are more than 4032 records returned.
s
have you tried checking the governance with runtime to be 100% sure its not that?
a
I have.
s
you arent using 2.1 are you?
a
Nope. 2.x
Should I set it 2.0 explicitly?
s
you can try, should be using 2.0 though
a
The execution is running now... on 4032 records... no failures. I'll need to wait to trigger it again.
Thanks for your help, I do appreciate the input.
s
Don't feel like much help was contributed except yep that's weird
a
Yep it's weird. 9 years, I've seen weird stuff in NetSuite. Nothing this weird. 🤷
Open in Slack
PreviousNext
Powered by