about summary refs log tree commit diff
path: root/tvix/docs/component-flow.puml
diff options
context:
space:
mode:
authorFlorian Klink <flokli@flokli.de>2022-09-15T16·03+0200
committerflokli <flokli@flokli.de>2022-09-16T11·55+0000
commitd8f667e01efcb3e76ba1d4ce65df5d3c582076ec (patch)
tree746945d9325155652cb00716c67ab19736f9f3a3 /tvix/docs/component-flow.puml
parentf859751c6a612205740698d67e083efe5cc4ee5e (diff)
docs(tvix): Update components.md r/4870
This extends various ideas around the store and its slightly different
internal model.

Thanks to store composition, lazy substitution and more efficient
transfer, we can also simplify some complicated logic while building.

Change-Id: Ib3380af650fe06e114f54e8dc2df231f18af876b
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6585
Autosubmit: flokli <flokli@flokli.de>
Tested-by: BuildkiteCI
Reviewed-by: tazjin <tazjin@tvl.su>
Diffstat (limited to 'tvix/docs/component-flow.puml')
-rw-r--r--tvix/docs/component-flow.puml20
1 files changed, 3 insertions, 17 deletions
diff --git a/tvix/docs/component-flow.puml b/tvix/docs/component-flow.puml
index 3bcddbe7464e..5b6d79b82313 100644
--- a/tvix/docs/component-flow.puml
+++ b/tvix/docs/component-flow.puml
@@ -28,7 +28,7 @@ note right
     Immediately starts streaming derivations as they are instantiated across
     the dependency graph so they can be built while the evaluation is still running.
 
-    There are two types of build requests: One for regular "fire and forget" builds
+    There are two types of build requests: One for regular "fire and forget" builds,
     and another for IFD (import from derivation).
 
     These are distinct because IFD needs to be fed back into the evaluator for
@@ -42,27 +42,13 @@ loop while has more derivations
         Coord<--Store: Success response
     else Store does not have path
         Coord-->Build: Request derivation to be built
-        note left
-            The build request optionally includes a desired store.
-            If a builder is aware of how to push to the store it will do so
-            directly when the build is finished.
-
-            If the store is not known by the builder results will be streamed
-            back to the coordinator for store addition.
-        end note
 
         alt Build failure
             Coord<--Build: Fail response
             note left: It's up to the coordinator whether to exit on build failure
         else Build success
-            alt Known store
-                Build-->Store: Push outputs to store
-                Build<--Coord: Send success & pushed response
-            else Unknown store
-                Build<--Coord: Send success & not pushed response
-                Coord<--Build: Stream build outputs
-                Coord-->Store: Push outputs to store
-            end
+            Build-->Store: Push outputs to store
+            Build<--Coord: Send success & pushed response
         end
 
     end