Skip to content

Fix order-dependent DesignManagement::SaveDesignsService spec

This spec uses build_stubbed, which uses IDs starting at 1000 and incrementing on their own internal counter. It appears that we had a combination of specs where this ID matched an actual database ID of a user with access (probably developer in this spec file), which is unlikely but not impossible.

By using non_existing_record_id as the ID for this stubbed record, we ensure that can't happen.

See #325544 (comment 534807843) for more speculation here.

Merge request reports

Loading