Add details on new Sidekiq workers and canary deploys

doc/development/sidekiq_style_guide.md

@@ -719,6 +719,23 @@ possible situations:
 1. A job is queued by a node running the newer version of the application, but
    executed on a node running an older version of the application.
 
+### Adding new workers
+
+On GitLab.com, we [do not currently have a Sidekiq deployment in the
+canary stage](https://gitlab.com/gitlab-org/gitlab/-/issues/19239). This
+means that a new worker than can be scheduled from an HTTP endpoint may
+be scheduled from canary but not run on Sidekiq until the full
+production deployment is complete. This can be several hours later than
+scheduling the job. For some workers, this will not be a problem. For
+others - particularly [latency-sensitive
+jobs](#latency-sensitive-jobs) - this will result in a poor user
+experience.
+
+This only applies to new worker classes when they are first introduced.
+As we recommend [using feature flags](feature_flags/) as a general
+development process, it's best to control the entire change (including
+scheduling of the new Sidekiq worker) with a feature flag.
+
 ### Changing the arguments for a worker
 
 Jobs need to be backward and forward compatible between consecutive versions