fix(mssql): force transactions if attempting to insert more than 1,000 rows

[evanrittenhouse]

Pull Request Checklist

• Have you added new tests to prevent regressions?
• If a documentation update is necessary, have you opened a PR to the documentation repository?
• Did you update the typescript typings accordingly (if applicable)?
• Does the description below contain a link to an existing issue (Closes #[issue]) or a description of the issue you are solving?
• Does the name of your PR follow our conventions?

Description Of Change

Force a transaction to be used if we're attempting to insert more than 1,000 rows in a single bulkInsert. This allows us to safely rollback everything in case it fails.

This fixes #15426.

[ephys]

A few notes but overall looks good :)

[ephys]

Ah, looks like this change causes an unexpected deadlock?

[evanrittenhouse]

Yep, need to investigate why - it passes the integration tests locally which is a bit odd, so I'll have to check into what's going on with our GH action.

[evanrittenhouse]

Converting to draft since I can't get the test failures repro'd locally - will need to push a lot

[WikiRik]

I was interested by the failing tests and it's a weird one.
Where I ended up is that the difference between the old code and the current code is in this line;

https://github.com/evanrittenhouse/sequelize/blob/9ffe2b1a2d95a61b559aa4d58ce542c2f6577c10/src/model.js#L2780

The inputs (associationInstances and includeOptions) are the same, but instances before running that is the same in both versions but instances after that is different.

I'm using the following test to debug;
https://github.com/evanrittenhouse/sequelize/blob/9ffe2b1a2d95a61b559aa4d58ce542c2f6577c10/test/integration/model/bulk-create/include.test.js#L12-L84

In this case the UserId in Product is null instead of 1 or 2, which causes the test to fail. Weird stuff

[evanrittenhouse]

@WikiRik you're saying the same inputs are applied to the same input array but are yielding different results?