Skip to main content

Apply queue concurrency changes on promotion, not on deploy

Feature Request

Right now, queue concurrency limits set in code take effect as soon as a deployment is built, even with --skip-promotion, and promoting or rolling back doesn't restore them. Queue settings should switch over with the version that's promoted, so a deploy waiting for approval can't change how the live version runs.

Posted by Iss Haddad ·
1 comment

Comments1

  • Iss Haddad

    Team•

    Oct 20

    Same applies to declarative cron schedules (schedules.task). They're synced as soon as a deployment is built, so with --skip-promotion a new release can already add, change or remove production crons before it's promoted. They should switch over on promotion too, and rolling back should restore the previous schedules.