Add buffer size and dropped actions fields to ScheduleInfo #311
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ShahabT
changed the title
|
Can you add a bit more to the "why", as in specifically how users may use it? |
ShahabT
force-pushed
the
shahab/OSS-1374
branch
from
0ccdd10
to
fba7a44
Compare
|
It's basically just for visibility and completeness. Buffer overruns are already exposed in a metric, but we have similar fields in ScheduleInfo for number of runs skipped, etc. so I think it should go there too. Buffer size is also interesting to monitor, but it doesn't make sense as a metric, it's more useful as a per-schedule thing to check with DescribeSchedule. I could imagine:
|
dnr
reviewed
Sep 1, 2023
Comment on lines
328
to
329
| // Number of actions dropped due to the buffer limit. | ||
| int64 buffer_dropped = 11; |
There was a problem hiding this comment.
I'd put this above in a group with the other counters. buffer_size is a gauge and more related to running_workflows.
|
Makes sense. I may request a bit more detail into what the "buffer" is on the proto comment. For example, I don't know whether buffer is used for future calendar/interval or just backlog of backfill or otherwise pending actions from the past. |
dnr
approved these changes
Sep 1, 2023
cretz
approved these changes
Sep 5, 2023
ShahabT
added a commit
to temporalio/temporal
that referenced
this pull request
Sep 6, 2023
<!-- Describe what has changed in this PR --> **What changed?** Expose buffer size and number of dropped actions due to buffer limit in ScheduleInfo Related API change: temporalio/api#311 <!-- Tell your future self why have you made these changes --> **Why?** Give more visibility into schedule state to the clients. <!-- How have you verified this change? Tested locally? Added a unit test? Checked in staging env? --> **How did you test it?** None so far <!-- Assuming the worst case, what can be broken when deploying this change to production? --> **Potential risks** None <!-- Is this PR a hotfix candidate or require that a notification be sent to the broader community? (Yes/No) --> **Is hotfix candidate?** No
dnr
pushed a commit
to dnr/temporal
that referenced
this pull request
Oct 30, 2023
…4839) <!-- Describe what has changed in this PR --> **What changed?** Expose buffer size and number of dropped actions due to buffer limit in ScheduleInfo Related API change: temporalio/api#311 <!-- Tell your future self why have you made these changes --> **Why?** Give more visibility into schedule state to the clients. <!-- How have you verified this change? Tested locally? Added a unit test? Checked in staging env? --> **How did you test it?** None so far <!-- Assuming the worst case, what can be broken when deploying this change to production? --> **Potential risks** None <!-- Is this PR a hotfix candidate or require that a notification be sent to the broader community? (Yes/No) --> **Is hotfix candidate?** No
rodrigozhou
pushed a commit
to temporalio/temporal
that referenced
this pull request
Oct 31, 2023
<!-- Describe what has changed in this PR --> **What changed?** Expose buffer size and number of dropped actions due to buffer limit in ScheduleInfo Related API change: temporalio/api#311 <!-- Tell your future self why have you made these changes --> **Why?** Give more visibility into schedule state to the clients. <!-- How have you verified this change? Tested locally? Added a unit test? Checked in staging env? --> **How did you test it?** None so far <!-- Assuming the worst case, what can be broken when deploying this change to production? --> **Potential risks** None <!-- Is this PR a hotfix candidate or require that a notification be sent to the broader community? (Yes/No) --> **Is hotfix candidate?** No
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What changed?
Adding two fields to ScheduleInfo proto
Why?
This is for visibility and completeness. Buffer overruns are already exposed in a metric, but we have similar fields in ScheduleInfo for number of runs skipped, etc. so I think it should go there too.
Buffer size is also interesting to monitor, but it doesn't make sense as a metric, it's more useful as a per-schedule thing to check with DescribeSchedule. I could imagine:
How did you test it?
No test
Potential risks
None
Is hotfix candidate?
No