[Bug]: update_event/v1 persists unexpected top-level `event` field from API wrapper

[matt-rgx]

Is there an existing issue for this?

• I have searched the existing issues

What happened?

Summary

update_event/v1 accepts and persists an unexpected top-level event property when it is included in the update payload.

This can happen accidentally when a client fetches an event with get_event/v1, manipulates the returned object, and sends it back to update_event/v1 without fully stripping response wrapper data.

Observed Behavior

get_event/v1 returns a response shaped like:

{
  "code": 0,
  "event": {
    "id": "event_id",
    "title": "Example Event",
    "workflow": {},
    "revision": 1
  },
  "jobs": [],
  "queued": 0
}

If an update payload contains an unexpected top-level event property inside the event object, for example:

{
  "id": "event_id",
  "title": "Example Event",
  "workflow": {},
  "revision": 1,
  "event": {
    "id": "event_id",
    "title": "Old Nested Event"
  }
}

then update_event/v1 stores that nested event object as part of the event record.
A later clean update that omits the event property does not remove it, because the endpoint performs a shallow merge.

Expected Behavior

update_event/v1 should not persist unknown top-level fields that are not part of the Event data model.
Ideally, the endpoint should either:

• reject unknown top-level properties with a validation error, or
• ignore/drop unknown top-level properties before persisting the update.
  At minimum, wrapper-related fields such as event, jobs, queued, and code should never be persistable into an event record.

Operating System

Deb 13

Node.js Version

22

xyOps Version

1.0.85

Server Setup

Single Conductor

Storage Setup

Default (SQLite + Filesystem)

Relevant log output

Code of Conduct

• I agree to follow this project's Code of Conduct

[jhuckaby]

Thank you for the issue report!

Actually, this behavior is well known, and quite endemic. All write API endpoints support this, as it was designed with this very thing in mind. You can create or update virtually anything in xyOps (assuming your API key has the appropriate privileges) and add your own custom keys to the objects, which are persisted in storage. It's actually a "feature", believe it or not. It's so you can extend the data structures with your own custom user-defined data.

I do have a long-term TODO item to redress this, possibly in v2, and potentially harden all the APIs and reject unknown keys, but it may take me a while to get to it. It's a big policy reversal, and a large code change across the entire codebase, and a feature that I have baked into all my apps for decades.

I think long term it would probably be better to expose a specific top-level property name like userData, which is freeform and can be populated with whatever the user wants, but then lock down the other top-level data structured. But again, this is a very, very, very large policy reversal, design change, and code change across the board.

This is probably a v2 thing.

[github-actions]

This issue has had no activity for 7 days, so it is being marked stale. If there is still no follow-up in 3 more days, it will be closed automatically.