You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This PR adds support for emitting "transient" messages to dataspaces.
Currently, dataspaces (aka DataspaceRegistry) allow for assertion/retraction of "facts": values that are set (and sometimes updated) over the lifecycle of a process but are always attached to that particular process from which they were asserted, automatically removed when the process stops. In some cases, however, we want to communicate values that can live beyond the lifecycle of a process without abusing the assertion/retraction pattern... otherwise, callers would have to try and figure out when they should pay attention to retractions vs when they don't need to, which is something we'd rather not do at all.
This PR adds support for emitting "transient" messages to dataspaces to support this lifecycle-less model of communication. In Syndicated Actors, where the concept of dataspaces originates from, this is actually an officially supported pattern, so really we're just bringing our implementation of dataspaces up to parity. 😅
In no specific order:
we changed AssertionUpdate to DataspaceUpdate since there's now a new enum variant for messages that is unrelated to assertions
there's a new method, DataspaceRegistry::send, for sending transient messages
transient messages have the same properties -- strongly typed, carries an identifier -- as assertions, but aren't tied to a process
messages come in alongside assertions/retractions on a given subscription
messages are only sent to active subscribers: they're never stored or replayed (hence "transient")
We're not optimizing for performance here since there's no use case (yet?) that requires this to act as a high-performance event bus.
Run ID:0037e60f-9d4e-4128-b1f7-85aaa68c447f Baseline:c4804620 · Comparison:9e4891a4 · diff
Optimization Goals: ✅ No significant changes detected
Fine details of change detection per experiment (5)
Experiments configured erratic: true are tagged (ignored) and skipped when determining which experiments regressed or improved. Experiments which are detected as erratic at runtime are tagged (erratic) to flag that the run's sample dispersion was high, but their regression / improvement signal still counts.
A change is flagged as a regression when |Δ mean %| > 5.00% in the regressing direction for its optimization goal AND SMP marks the experiment as a regression (is_regression: true). Improvements use the matching criteria for the improving direction. Experiments configured erratic: true (tagged (ignored)) are skipped outright; experiments detected as erratic at runtime (tagged (erratic)) still count, since that flag describes sample dispersion rather than directional certainty. The Δ mean % cell is colored accordingly: 🟢 = improvement, 🔴 = regression, ⚪ = neutral. Reduction in CPU or memory is an improvement; reduction in ingress throughput is a regression.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR adds support for emitting "transient" messages to dataspaces.
Currently, dataspaces (aka
DataspaceRegistry) allow for assertion/retraction of "facts": values that are set (and sometimes updated) over the lifecycle of a process but are always attached to that particular process from which they were asserted, automatically removed when the process stops. In some cases, however, we want to communicate values that can live beyond the lifecycle of a process without abusing the assertion/retraction pattern... otherwise, callers would have to try and figure out when they should pay attention to retractions vs when they don't need to, which is something we'd rather not do at all.This PR adds support for emitting "transient" messages to dataspaces to support this lifecycle-less model of communication. In Syndicated Actors, where the concept of dataspaces originates from, this is actually an officially supported pattern, so really we're just bringing our implementation of dataspaces up to parity. 😅
In no specific order:
AssertionUpdatetoDataspaceUpdatesince there's now a new enum variant for messages that is unrelated to assertionsDataspaceRegistry::send, for sending transient messagesWe're not optimizing for performance here since there's no use case (yet?) that requires this to act as a high-performance event bus.
Change Type
How did you test this PR?
New and existing tests.
References
DADP-2