WarpDrive: transactional notification delivery and reactive request state - #1232
WarpDrive: transactional notification delivery and reactive request state#1232runspired wants to merge 2 commits into
Conversation
…equest state Proposes replacing WarpDrive's five notification flush timing policies with a single invariant -- all store-managed writes happen inside a transaction and publish in one synchronous batch at its close -- and rebuilding RequestStateService as transactionally-written, signals-backed data. Leaves the public reactive-request-subscription API shape, the perf-sensitive internal transaction shape, and coordination with the Render Aware Scheduler interface (emberjs#957) as unresolved questions for the Exploring stage. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017CMTUUPwpZXGjqCM8nUDrP
runspired
added
T-ember-data
Post-open template housekeeping now that the Proposal PR is open at emberjs#1232. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017CMTUUPwpZXGjqCM8nUDrP
runspired
changed the title
| consistent now" point. | ||
|
|
||
| These are all partial answers to one question — *when is the current unit of | ||
| work done?* — using three incompatible definitions of "unit of work." |
There was a problem hiding this comment.
a note on this we should record: this complexity grew out of a forced requirement that emberjs is in the process of removing via #957
because ember historically would render synchronously, and because it hijacked RSVP's promise flush to schedule a render - one if not many renders could occur in the middle of a microtask queue flush interleaved with WarpDrive's work to handle a request response.
While interleaving will not stop being an issue, the move to transactions makes observing state at any moment in time safer, while Ember's move away from rendering in-the-middle-of-thing will remove the risk application's often experienced in this area. A primary focus of the existing flush configuration is buffering notify until the finally of the last microtask used to yield the request response back to the consumer - thereby attempting to avoid any application re-renders occurring prior to the requesting call-site itself having had the opportunity to process the result. With ember moving away from the dangerous semantics it had, this will no longer be a threat and we can simplify our internals and the maintenance burden.
This rises to the level of RFC instead of an internal design choice for 3 reasons:
- the timing of this change needs to be somewhat coordinated with landing the new scheduler and fixing Ember's flush.
- the RequestStateService which we have always planned to revisit to produce a simpler API currently does not participate in our coordinated notifications system and will need to
- these timing changes for flush are user observable, and historically changes to them - even when to make it more correct or safer - have resulted in test failures in consuming apps where tests had become reliant on a specific interleaving of render and microtask ordering.
| mutate → coalesce → sync → notify → cleanup | ||
| ``` | ||
|
|
||
| - `mutate` is the transaction body; `coalesce` and `sync` are the graph's |
There was a problem hiding this comment.
WarpDrive's existing _run and _join implementation are intentionally optimized for low memory overhead and high execution speed. Storing callbacks is inherently risky for perf - we will have to analyze the tradeoff. This may call for a linked list.
There was a problem hiding this comment.
(note that despite the similarity in method names and purpose, WarpDrive's internal run/join/schedule/flush mechanism today is not intended to be a microtask polyfill like backburner was. It is not possible to have safe transactions in async code: this is purely a work ordering mechanism to enable a safe sync progression through work to be completed)
| store.push(payloadB); | ||
| record.name = 'Chris'; | ||
| }); // one publication | ||
| ``` |
There was a problem hiding this comment.
we're missing a deeper store teardown/unloadAll handling explanation here. Today these situations are highly optimized to intentionally sever notifications, remove subscribers, and teardown associated state as quickly as possible in an order the prevents additional work being triggered or the internals from churning/recreating objects. We will still want those optimizations.
2 participants
Propose WarpDrive: transactional notification delivery and reactive request state
Rendered
Summary
This pull request is proposing a new RFC.
To succeed, it will need to pass into the Exploring Stage, followed by the Accepted Stage.
A Proposed or Exploring RFC may also move to the Closed Stage if it is withdrawn by the author or if it is rejected by the Ember team. This requires an "FCP to Close" period.
An FCP is required before merging this PR to advance to Accepted.
Upon merging this PR, automation will open a draft PR for this RFC to move to the Ready for Released Stage.
Exploring Stage Description
This stage is entered when the Ember team believes the concept described in the RFC should be pursued, but the RFC may still need some more work, discussion, answers to open questions, and/or a champion before it can move to the next stage.
An RFC is moved into Exploring with consensus of the relevant teams. The relevant team expects to spend time helping to refine the proposal. The RFC remains a PR and will have an
Exploringlabel applied.An Exploring RFC that is successfully completed can move to Accepted with an FCP is required as in the existing process. It may also be moved to Closed with an FCP.
Accepted Stage Description
To move into the "accepted stage" the RFC must have complete prose and have successfully passed through an "FCP to Accept" period in which the community has weighed in and consensus has been achieved on the direction. The relevant teams believe that the proposal is well-specified and ready for implementation. The RFC has a champion within one of the relevant teams.
If there are unanswered questions, we have outlined them and expect that they will be answered before Ready for Release.
When the RFC is accepted, the PR will be merged, and automation will open a new PR to move the RFC to the Ready for Release stage. That PR should be used to track implementation progress and gain consensus to move to the next stage.
Checklist to move to Exploring
S-Proposedis removed from the PR and the labelS-Exploringis added.Checklist to move to Accepted
Final Comment Periodlabel has been added to start the FCP