[Feature Request] Add information in visibility that distinguishes between a deprecated and non deprecated patch
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- rust
- Domain
- backend-api-design
Research direction
Start by reviewing the patched and deprecatePatch APIs and how the TemporalChangeVersion search attribute is emitted. The work is done when visibility queries can distinguish deprecated patches from non-deprecated patches without fetching and inspecting all workflow histories.
Written by the indexing model from the issue text.
Description
Part of the design for the patched and deprecatePatch APIs included a method for users to verify when old code branches can be removed and when deprecated patches can be removed from workflow code.
It's safe to remove patches once there are only workflow histories that include the deprecated version of a patch.
Core adds the TemporalChangeVersion search attribute when emitting a patch marker but does not add information on the deprecation status of that patch.
Users can get around it by fetching all workflow histories and inspecting the patch markers but that's far from optimal.
Describe the solution you'd like
Have some method to distinguish between deprecated and non deprecated patches via visibility queries.
- Dominant language
- Rust
- Stars
- 539
- Forks
- 170
- Avg merge
- 3d 2h
- Merged PRs (30d)
- 41
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from temporalio/sdk-rust
-
[Bug] Resource-based Worker Tuner falls back to host-wide CPU usage in cgroup v1 containersPossibly taken @TiunovNN claimed this today. Openbug
Difficulty 4/5 3-5 days Newbie friendliness 35/100
temporalio/sdk-rust#1701 ·
Maintainers usually reply within 1 day
-
[Bug] Local Activity retries indefinitely when ScheduleToClose expires between in-process retriesPossibly taken @dannyward630 claimed this 9 days ago. Openbug
Difficulty 4/5 3-5 days Newbie friendliness 30/100
temporalio/sdk-rust#1657 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
temporalio/sdk-rust#1653 ·
Maintainers usually reply within 1 day
-
Enable concurrent payload visiting - RustPossibly taken @jmaeagle99 claimed this 12 days ago. Open
temporalio/sdk-rust#1650 · 1 assignee ·
Maintainers usually reply within 1 day
-
External Payload Storage Foundation - RustPossibly taken @jmaeagle99 claimed this 16 days ago. Open
temporalio/sdk-rust#1643 · 1 assignee ·
Maintainers usually reply within 1 day
All issues in temporalio/sdk-rust
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
manuscript-lang/manuscript#1364 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
fable-compiler/Fable#5157 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 73/100
Maintainers usually reply within 1 day
-
C-bug needs-triage O-UEFI T-libs
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day