GO-75 Set jobs priority #461
Conversation
|
@luciajanikova moj nazor na priority jobov je nasledovny: Vzdy sa na to treba pozerat z pohladu SLA voci zakaznikovi. Cize za mna:
Ciselne priority nemam uplne rad lebo v tom sa hned zamotas (uz len to ze ci nizke cislo alebo vysoke ide skor). Lepsie je to nazvat nejako rozumne: Druhy pohlad je, vyrabat queue na kazdy job - to ma vyhodu, ze pripadne vies nejake typy jobov vypnut, ale to u nas netreba. |
# Conflicts: # app/jobs/govbox/process_message_job.rb
app/models/govbox/message.rb
Outdated
| @@ -25,7 +25,7 @@ class Govbox::Message < ApplicationRecord | |||
|
|
|||
| DELIVERY_NOTIFICATION_TAG = 'delivery_notification' | |||
|
|
|||
| def self.create_message_with_thread!(govbox_message) | |||
| def self.create_message_with_thread!(govbox_message, priority: :default) | |||
There was a problem hiding this comment.
Tu sme si @jsuchal povedali, nech si radsej posielame kontext do tejto metody ako prioritu (a vo vnutri metody to prelozime na prioritu). Vidim vsak v tom trochu problem, lebo kontext moze byt rozny. Inicialny import (nizka priorita), stahovanie spravy do vlast. ruk po prevzati dorucenky (vysoka priorita) alebo ziadny kontext (default priorita).
A tento kontext nemame velmi ako v ProcessMessageJobe (ktory vola tuto metodu) poznat, museli by sme si ho tam posielat napriec viacerymi jobmi, aby vedel prebublat az sem.
# Conflicts: # test/fixtures/message_object_data.yml # test/fixtures/message_objects.yml # test/system/message_drafts_test.rb
| t.enum "color", enum_type: "color" | ||
| t.integer "tag_groups_count", default: 0, null: false | ||
| t.string "icon" | ||
| t.integer "tag_groups_count", default: 0, null: false | ||
| t.enum "color", enum_type: "color" | ||
| t.index "tenant_id, type, lower((name)::text)", name: "index_tags_on_tenant_id_and_type_and_lowercase_name", unique: true | ||
| t.index ["owner_id"], name: "index_tags_on_owner_id" | ||
| t.index ["tenant_id", "type"], name: "signings_tags", unique: true, where: "((type)::text = ANY (ARRAY[('SignatureRequestedTag'::character varying)::text, ('SignedTag'::character varying)::text]))" | ||
| t.index ["tenant_id", "type"], name: "signings_tags", unique: true, where: "((type)::text = ANY ((ARRAY['SignatureRequestedTag'::character varying, 'SignedTag'::character varying])::text[]))" |
There was a problem hiding this comment.
Ani tieto zmeny sa podla mna netykaju tohto PR.
There was a problem hiding this comment.
Toto som recreate from scratch cize toto sa tam udialo. neviem preco
Prvy nastrel pridania priorit k jobom. Uvazujem, ci takto hadzat priority k jednotlivym jobom alebo si radsej spravit queues podla priority. Prve priblizenie som zatial dala cez priority.
Pri initial UPVS importe sa mi podarilo posuvat prioritu cez vsetky joby, az na tento event:
https://github.com/slovensko-digital/govbox-pro/blob/main/app/lib/event_bus.rb#L36-L38, ktory sa vyvola po vytvoreni spravy. Tam neviem ako by sme to rozumne posunuli.
Initial UPVS import: nizka priorita (100)
Pravidelne stahovanie updates UPVS, FS formularov: najnizsia priorita (1000)
Userom vyvolany sync: najvyssia priorita (-1000)
Prevzatie spravy do vlastnych ruk: najvyssia priorita (-1000)