FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

Fix duplicate RUNNING_VM helper record creation on repeated VM.START events by SURYAS1306 · Pull Request #12606 · apache/cloudstack · GitHub

  1. apache
  2. cloudstack

Repository navigation

Fix duplicate RUNNING_VM helper record creation on repeated VM.START events - #12606

Closed
SURYAS1306 wants to merge 1 commit into
apache:mainfrom
SURYAS1306:fix-duplicate-running-vm-usage
ConversationCommits (1)ChecksFiles changed
Closed

Fix duplicate RUNNING_VM helper record creation on repeated VM.START events#12606
SURYAS1306 wants to merge 1 commit into
apache:mainfrom
SURYAS1306:fix-duplicate-running-vm-usage

Conversation

SURYAS1306 commented Feb 6, 2026 •
edited
Loading

Copy link
Copy Markdown

Description

Repeated VM.START events for the same VM could result in duplicate
RUNNING_VM helper usage records being created in the usage database.

This PR adds a defensive check in UsageManagerImpl#createVMHelperEvent
to detect an existing active RUNNING_VM usage record (same VM instance,
endDate = NULL) and skip helper record creation when a duplicate START
event is received.

A regression test has been added to ensure that duplicate RUNNING_VM
helper records are not created when repeated VM.START events are
processed.

Fixes: #12590

Expected behavior

Only one active RUNNING_VM usage helper record should exist per VM at
any given time.

Actual behavior

Multiple RUNNING_VM helper records could be created for the same VM
when duplicate VM.START events were processed.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • Test (unit or integration test code)

Bug Severity

  • Minor

How Has This Been Tested?

  • Added a unit test in UsageManagerImplTest to verify that duplicate
    RUNNING_VM helper records are not created when repeated VM.START
    events are handled.
  • Built and tested the cloud-usage module successfully using Maven.

How did you try to break this feature and the system with this change?

  • Simulated repeated VM.START events for the same VM instance to ensure
    that helper record creation is skipped when an active RUNNING_VM
    record already exists.

boring-cyborg Bot commented Feb 6, 2026

Copy link
Copy Markdown

Congratulations on your first Pull Request and welcome to the Apache CloudStack community! If you have any issues or are unsure about any anything please check our Contribution Guide (https://github.com/apache/cloudstack/blob/main/CONTRIBUTING.md)
Here are some useful points:

DaanHoogland commented Feb 9, 2026

Copy link
Copy Markdown
Contributor

Thank you @SURYAS1306 , can you rebase this on the 4.20 branch?

abh1sar reviewed Feb 9, 2026
View reviewed changes

abh1sar left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Thanks for working on this @SURYAS1306 .
But skipping insertion into the usage_vm_instance table is not the right approach.

id type account_id created count resource_id name
106 VM.START 6 2025-10-27 13:02:07 2 200 fedora
107 VM.STOP 6 2025-10-27 13:02:06 2 200 fedora
108 VM.START 6 2025-10-27 13:02:07 2 200 fedora

In the example above, if we skip the last event, it will cause usage to never register the Instance as started and it will not be billed properly.

SURYAS1306 commented Feb 9, 2026

Copy link
Copy Markdown
Author

Thanks for the review.

That makes sense skipping the helper record creation could indeed cause the VM state to be inconsistent and affect billing.

I'll revisit the approach and focus on handling duplicate VM.START events in a way that keeps the usage state correct (likely by making the processing idempotent rather than skipping the event).

I'll rework the fix and update the PR.

abh1sar commented Feb 11, 2026

Copy link
Copy Markdown
Contributor

Thanks for the review.

That makes sense skipping the helper record creation could indeed cause the VM state to be inconsistent and affect billing.

I'll revisit the approach and focus on handling duplicate VM.START events in a way that keeps the usage state correct (likely by making the processing idempotent rather than skipping the event).

I'll rework the fix and update the PR.

Thanks, can you turn the PR into Draft until then?

DaanHoogland marked this pull request as draft February 11, 2026 11:02
SURYAS1306 mentioned this pull request Feb 19, 2026
Closed
winterhazel self-requested a review February 27, 2026 13:52
This was referenced Jun 1, 2026
Closed
Closed

github-actions Bot commented Jun 28, 2026

Copy link
Copy Markdown

This PR is stale because it has been open for 120 days with no activity. It may be removed by administrators of this project at any time. Remove the stale label or comment to request for removal of it to prevent this.

weizhouapache modified the milestones: 4.24.0, 4.20.4 Jun 29, 2026
DaanHoogland force-pushed the fix-duplicate-running-vm-usage branch from be8423c to d6e0889 Compare August 4, 2026 07:49
DaanHoogland moved this from Backlog to conflict/waiting in CloudStack Testing Sep 1, 2026

DaanHoogland commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

@abh1sar @SURYAS1306 this seem a duplicate to #13019 which is merged. closing this but please re-open if in err

github-project-automation Bot moved this from conflict/waiting to Done in CloudStack Testing Sep 1, 2026
This file contains hidden or 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
Show hidden characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

abh1sar abh1sar left review comments
winterhazel Awaiting requested review from winterhazel

Assignees

No one assigned

Labels

component:usage-server

Projects

None yet

Milestone

4.20.4

Development

Successfully merging this pull request may close these issues.

Duplicate event for VM.START in the usage_event causes it to never get processed

4 participants

Back | FazBrowse Home | New Git URL