I logged a case with Servicenow Support and this was their response
*Most Probable Cause: *
> The unique identifier for all records, including duplicate records in
> ServiceNow, is the respective sys_id generated by the system.
> By default, ServiceNow does not enforce uniqueness on the task.number
> column. This opens the possibility of having records with the same number. (Not sure why Servicenow does not enforce uniqueness on the task.number, this would save a lot of time and inconsistencies!!)
>
> Reason 1:
> The issue can occur from multiple pushes being made to the submit button.
> Although generally this is in conjunction with a network latency issue
> (i.e. where a push is sent and upon reconnection, another push is sent
> separately), it can simply occur without.
>
> Reason 2:
> One possibility is if there is a double insert caused by a custom business
> rule that contains a current.update or an .update when the record is
> inserted.
> — please kindly review the custom business rule on insert using
> current.update() or gr.update or *.update
>
> Reason 3:
> One scenario is where you cloned over from production and production
> already have that number.
>
>
> *Solution Proposed: *
> As of now, unless there is a way to reproduce this issue, or if there is
> some type of pattern of the issue, it would be difficult to pin point what
> may cause the issue.
>
> To impose the unique numbering on task table via a Business rule so that
> duplicate numbers will not be created. Before every update, it will make
> sure that a new number is assigned to the record.
>
>
> https://docs.servicenow.com/bundle/utah-platform-administration/page/administer/field-administration...
>
