Clarified checkpoint state implications when changing storage accounts or recreating the Event hub.#128527
Clarified checkpoint state implications when changing storage accounts or recreating the Event hub.#128527ffarinha-msft wants to merge 2 commits into
Conversation
Clarified checkpoint state storage details and implications of changing storage accounts or recreating the Event hub.
|
@ffarinha-msft : Thanks for your contribution! The author(s) and reviewer(s) have been notified to review your proposed change. |
|
Learn Build status updates of commit 417c92a: ✅ Validation status: passed
For more details, please refer to the build report. |
|
Can you review the proposed changes? IMPORTANT: When the changes are ready for publication, adding a #label:"aq-pr-triaged" |
prmerger-automator
Bot
added
the
aq-pr-triaged
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Clarifies how Azure Functions Event Hubs checkpointing behaves when the Storage account is changed or when an Event Hub is deleted and recreated, emphasizing potential implications for event processing continuity.
Changes:
- Added documentation explaining that checkpoint state persists in the configured Storage account.
- Documented implications of switching Storage accounts (loss of prior checkpoint context) and recreating an Event Hub (stream position reset vs. persisted checkpoints).
- Noted that stale checkpoints can prevent new events from being processed until checkpoints are deleted.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| Your code and dependent systems might need to account for the fact that the same event could be processed twice. For more information, see [Designing Azure Functions for identical input](functions-idempotent.md). | ||
| - Checkpoint state is stored on the client side: | ||
|
|
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
|
Learn Build status updates of commit 63b4121: ✅ Validation status: passed
For more details, please refer to the build report. |
This PR aims to clarify checkpoint state storage details and implications of changing storage accounts or recreating the Event hub.
Namely that if an Event Hub is deleted and recreated, the event stream position (such as sequence numbers and offsets) is reset, while existing checkpoints on the Storage Account remain unchanged. In this scenario, the function might not process new events until the checkpoint state is manually reset by either recreating the storage account or just delete the blob files under azure-webjobs-eventhub/[EVENTHUB_NAMESPACE].servicebus.windows.net/[EVENTHUB_NAME]/[CONSUMER_GROUP]/checkpoint..
This scenario was discussed on ICM 51000001001837 and also on this Github issue Azure/azure-sdk-for-net#53741