VOLUME.CHANGE.DISK.OFFERING does not generate VOLUME.RESIZE usage event when volume size remains unchanged

[Yuliia7-1]

problem

When a volume's disk offering is changed to another offering with the same size, CloudStack does not emit a VOLUME.RESIZE event in cloud.usage_event

versions

ACS version is 4.19.1.1

The steps to reproduce the bug

Steps to reproduce:

Case 1 - Resized volume, same capacity after disk offering change

• Create Volume A using Disk Offering A with an initial size of 300 GB.
• Resize the volume to 400 GB.
• Change the disk offering from Disk Offering A to Disk Offering B, while keeping the volume size at 400 GB.
  Result: The disk offering change completed successfully, but no new VOLUME.RESIZE usage event was generated.

Case 2 - Fixed-size disk offerings with the same capacity

• Create Volume A using Disk Offering A with a fixed size of 400 GB.
• Change the disk offering to Disk Offering B, which also has a fixed size of 400 GB.
  Result: The disk offering was updated successfully, but no VOLUME.RESIZE usage event was generated.

Case 3 - Custom-size disk offerings with the same capacity

• Create Volume A using Disk Offering A with a custom size of 400 GB.
• Change the disk offering to Disk Offering B, while keeping the volume size at 400 GB.
  Result: The disk offering change completed successfully, however no VOLUME.RESIZE usage event was generated.

Case 4 - Disk offering change with a different volume size

• Create Volume A using Disk Offering A with a size of 300 GB.
• Change the volume to Disk Offering B and increase the volume size to 400 GB as part of the same operation.
  Result: CloudStack generated both the VOLUME.CHANGE.DISK.OFFERING event and a new VOLUME.RESIZE usage event, and the billing information was updated correctly.

Actual behaviour:

CloudStack generates a VOLUME.CHANGE.DISK.OFFERING event in the cloud.event table, confirming that the operation completed successfully.

However, no new VOLUME.RESIZE entry is created in the cloud.usage_event table.

As a result, the usage records continue to reference the previous disk offering, and downstream billing continues to use the old offering information.

Additional observations:

• The volume is successfully updated to Disk Offering B.
• The volume size remains unchanged.
• The latest cloud.usage_event entry still references Disk Offering A.
• Billing data derived from cloud.usage_event therefore continues to report the previous offering.

What to do about it?

Expected behaviour:

A usage event should be generated (or the existing usage information updated) so that the billing system reflects the new disk offering, even though the volume size has not changed.

[DaanHoogland]

The actual problem is not the resize not being send, but the lack of resize usage_event leading to not having the disk-offering changed.
Sending a resize event could be a solution, but some kind of other usage_event dispatch leading to the desired situation is also an option.
A bit more elaborate, but maybe more formally adherent to the actual situation would be to send a VOLUME.DESTROY and a VOLUME.CREATE, or (maybe in combination with) VOLUME.DETACH and VOLUME.ATTACH.
There is also a VOLUME.UPDATE and a defined but unused EVENT_VOLUME_DETAIL_UPDATE.
Finally defining a new event type would work as well.
@Yuliia7-1 , I suppose pricing is the issue here? ("billing" gave it away ;) )