fix: rm event line (#2338)

2026-05-03 16:09:37 -05:00 · 2025-09-24 17:17:21 -04:00
parent ee17433ac9
commit 046e47c135
1 changed files with 0 additions and 1 deletions
@@ -65,6 +65,5 @@ While we'd prefer to avoid any breaking changes, v1 is architecturally very diff
 - While we haven't published an official REST API doc, we have often recommended usage of the REST API in our SDKs to implement replays, retrieving task status, and dead-letter queueing. The current API for listing, cancelling and replaying workflow runs will not work against a v1 engine. We will be providing an upgrade path using new endpoints which are more conducive to bulk replays and cancellations.
 - We will only be supporting [CEL-based concurrency keys](./concurrency.mdx), and we will not be supporting custom concurrency methods defined on the client. If you require custom logic to compute the concurrency key that can't be captured in a CEL expression, we recommend computing the key ahead of time and passing it as part of the input to the workflow. **Workflows registered against a v1 engine with a custom concurrency method (instead of an expression) will not use a concurrency queue.**
 - Concurrency queues previously did not respect the `ScheduleTimeout` value set on the workflow level, so concurrency queues had no timeouts. In v1, concurrency queues will respect the schedule timeout value as well.
- User-defined events sent via `event.push` will no longer be displayed in the Hatchet UI and will not be available over the REST API. Events will still trigger workflows, but in nearly all instances of Hatchet that we surveyed, events were not used, accessed after writes, or replayed. We are considering adding an option to mark a user-defined event as `Durable`, but that will not be available in the initial v1 release. **Please let us know if you are dependent on the events view or APIs.**

 _These are the most important breaking changes, but we will add any small modifications to queueing/workflow behavior ahead of March 24th._