Improvements for API events
Description
Problem/Justification
None
Impact
None
Attachments
1
created by
is duplicated by
Activity
Show:

Caleb November 21, 2024 at 4:34 PM
we already send the response as the return from the crud methods, so just please use those returned objects in the meantime
we should probably consider adding events globally to middleware, however, this will have to be properly designed and implemented because it could potentially become very expensive.

William Gryzbowski November 21, 2024 at 12:32 PM
what existing code? Can you give examples of endpoints where it will return fields?
Pinned fields
Click on the next to a field label to start pinning.
Details
Details
Assignee

Reporter

Labels
Components
Affects versions
Priority

More fields
Time tracking
More fields
Time trackingKatalon Platform
Linked Test Cases, Katalon Defect Results, Katalon Studio Test Results
Katalon Platform
Linked Test Cases, Katalon Defect Results, Katalon Studio Test Results
Created November 21, 2024 at 8:37 AM
Updated January 27, 2025 at 3:44 PM
These changes would allow us to reuse existing code and remove a workaround to manage the collection state.
Example of websocket messages:
Actual result:
When creating a new instance:
added
event missingfields
propertyWhen start/stop/restart existing instance:
changed
event missing other instance fields exceptstatus
Expected result:
When creating a new instance:
added
event havefields
property with instanceWhen start/stop/restart existing instance:
changed
event have full instance fieldsNOTE: This is not a limitation of
virt.*
namespace. We just haven’t had sending events on crud events be global by design. It has always been an explicit feature that was added by the developer during the implementation of a plugin. We should consider sending events on CRUD events by default for all namespaces but that will have to come after we get the strictly versioned API feature complete. Also, adding this functionality will require careful consideration and design.