Hi everyone, I have a map/reduce script running that is creating multiple different record types. The records created have non sequential internal IDs that go up by the hundreds. Does anyone happen to know what the cause of this might be?

Pretty sure this is to be expected with Map/reduce scripts. The script is breaking the process down into different jobs, which are then handled by different suitecloud processors (engines)

Im the sole developer of it. Because of the nature of the process its better suited as a map reduce. Ive noticed this same effect in other script types and dont know if its just the 2.0 API, a setting somehwere, or just something that i may be overlooking. Its my current understanding that the concurrency shouldnt change anyting, in fact, im currently testing on one node and its still having the same effect.

Yeah, not sure either. I'm still learning suitescript

It's not limited to any specific API version, it can happen with a 1.0, 2.0, or 2.1 script, in any script type. What seems to happen is that the first record of a specific record type that a script instance creates reserves a block of 100 ids for that script instance, causing the next record created by any other means (manual, SuiteTalk, CSV import, other script or other deployment) to be at least a hundred higher. With Map/Reduce scripts, you have multiple queues going at the same time, essentially acting like multiple deployment of a scheduled script. Each queue will reserve and use up ids in blocks of a hundred. But, the thing to note is that internal ids are not, and never can be, guaranteed to increase sequentially in the order of record creation. All that NetSuite guarantees with internal ids is that they are unique. They are not supposed to have any meaning, they most definitely cannot be used to determine sequence or order of creation. It's best to pretend that even though the internal ids are numbers and generally increase over time, that they have no meaning, and might as well be random. Even switching to a scheduled script will not help, because if someone manually creates a record while the script is running, or a CSV import creates records while the script is running, you will have the exact same problem. You won't be guaranteed not to have gaps or to have the internal ids order by creation time.