mirror of
https://github.com/hanzoai/tasks.git
synced 2026-10-04 02:04:03 +00:00
David PorterandGitHub
5b362d52d3
## What changed? This adds a search attributes to schedulesV2: `TemporalScheduleNextActionTimeTime` - `TemporalScheduleNextActiontimeTime` Denotes when the next expected firing of the schedule should be. Ie, if a schedule fires every 5 minutes and it fired a minute ago, it should be 4 minutes in the future. ## Why? The intent is to add some broadly useful search values to visibility, both for customers, but also for operators who are interested in monitoring the behaviour of SchedulesV2. Because we're expecting to move to CHASM based scheduling hereafter, I've not attempted to backport these values to the V1 scheduler. ## How did you test it? - [ ] built - [ ] run locally and tested manually - [X] covered by existing tests - [X] added new unit test(s) - [X] added new functional test(s) Local tests: Verified that the schema is present Elasticsearch Upgrade path: ``` ./temporal-elasticsearch-tool -ep http://127.0.0.1:9200 \ update-schema --index temporal_visibility_v1_dev 2026-05-27T13:27:09.829-0700 INFO Starting template upgrade {"config": {"TemplateContent":"{\n ... 2026-05-27T13:27:09.962-0700 INFO Index mappings updated successfully {"indexName": "temporal_visibility_v1_dev", "logging-call-at": "/Users/dp/dev/t/temporal/tools/elasticsearch/tasks.go:198"} 2026-05-27T13:27:09.962-0700 INFO Index mapping update complete {"logging-call-at": "/Users/dp/dev/t/temporal/tools/elasticsearch/tasks.go:148"} $ curl -s "http://localhost:9200/temporal_visibility_v1_dev/_mapping" \ | jq '.temporal_visibility_v1_dev.mappings.properties.TemporalScheduleNextActionTime' { "type": "date_nanos" } ``` Postgres: ``` temporal_visibility=# INSERT INTO executions_visibility (namespace_id, run_id, workflow_id, start_time, execution_time, status, workflow_type_name, encoding, search_attributes) VALUES ( '00000000-0000-0000-0000-000000000001'::uuid, 'r1', 'w1', NOW(), NOW(), 1, 'test', 'Proto3', '{"TemporalScheduleNextActionTime": "2030-01-02T03:04:05Z"}'::jsonb ); INSERT 0 1 temporal_visibility=# select temporalschedulenextactiontime from executions_visibility; temporalschedulenextactiontime -------------------------------- 2030-01-02 03:04:05 (1 row) ``` mysql: ``` mysql> INSERT INTO executions_visibility (namespace_id, run_id, workflow_id, start_time, execution_time, status, workflow_type_name, encoding, search_attributes) VALUES ( '00000000-0000-0000-0000-000000000001', 'r1', 'w1', NOW(6), NOW(6), 1, 'test', 'Proto3', '{"TemporalScheduleNextActionTime": "2030-01-02T03:04:05Z"}' ); Query OK, 1 row affected (0.01 sec) mysql> SELECT TemporalScheduleNextActionTime -> FROM executions_visibility WHERE run_id = 'r1'; +--------------------------------+ | TemporalScheduleNextActionTime | +--------------------------------+ | 2030-01-02 03:04:05.000000 | +--------------------------------+ 1 row in set (0.00 sec) ``` ## Potential risks This does add a little more data to visibility, but as @lina-temporal mentioned, the NextActionTime is not actually a difference in the volume of writes to visibility. The Memo field is already being written every schedule firing.