Docs/0.0.2 #355
Docs/0.0.2 #355
Conversation
|
Caution Review failedThe pull request is closed. 📝 WalkthroughSummary by CodeRabbit
WalkthroughAdds and reorganizes Exosphere documentation: introduces Core Concepts, Fanout, Unite, Store, Graph Components, Graph Validation, and Python SDK guides; rewrites Create Graph/Runtime/Getting Started/Signals/Retry docs; removes the api-changes doc; updates navigation and theme colors; inserts many “Next Steps”/Related Concepts links. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant Client
participant Runtime
participant StateManager
participant DB
rect rgba(228,88,125,0.06)
note right of Runtime: Pull-based execution loop (docs focus)
Runtime->>StateManager: Poll for next state
StateManager->>DB: Read READY state
DB-->>StateManager: State document
StateManager-->>Runtime: Assign state (inputs, node)
Runtime->>Runtime: Execute node
alt success
Runtime->>StateManager: Report SUCCESS (outputs, store updates)
else error/signal
Runtime->>StateManager: Report ERRORED or Signal (requeue/prune)
end
StateManager->>DB: Persist status, outputs, store
StateManager->>StateManager: Create next states (fanout/unite)
end
Client->>StateManager: Upsert/Trigger graph
StateManager->>DB: Persist graph / enqueue initial state
DB-->>StateManager: Ack
StateManager-->>Client: Submission result
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: ASSERTIVE Plan: Pro 💡 Knowledge Base configuration:
You can enable these sources in your CodeRabbit configuration. 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @nk-ag, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request focuses on a comprehensive refactoring of the Exosphere project's documentation. The primary goal is to enhance clarity, organization, and discoverability of information by breaking down complex topics into smaller, more focused guides. This effort aims to provide a clearer learning path for users and improve the overall documentation experience.
Highlights
- Documentation Restructuring: The Exosphere documentation has undergone a significant overhaul, reorganizing content into a more modular and user-friendly structure.
- New Dedicated Concept Pages: New pages have been introduced for core Exosphere concepts such as Fanout, Unite, Signals, Retry Policy, and Store, providing in-depth explanations for each.
- Graph Documentation Enhancements: The 'Create Graph' guide has been refactored, with detailed explanations of graph components, validation rules, and Python SDK usage now residing in their own dedicated pages.
- Feature Stabilization: The 'beta' tags have been removed from the Retry Policy, Signals, and Store features, indicating their maturity and readiness for general use.
- Improved Navigation: The
mkdocs.ymlconfiguration has been updated to reflect the new documentation hierarchy, making it easier to navigate and discover information.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
This pull request introduces a major and well-executed refactoring of the documentation. It significantly improves the structure by breaking down large articles into smaller, concept-focused pages, and reorganizing the navigation for better usability. My review focuses on a few areas where the refactoring may have inadvertently removed useful information or introduced a potential issue in an example. The suggestions aim to restore this context and ensure the documentation remains comprehensive and accurate. Overall, this is an excellent update to the project's documentation.
coderabbitai
bot
added
the
documentation
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 39
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (15)
docs/docs/exosphere/dashboard.md (1)
206-215: Add blank lines around the new section for lint-friendly formattingInsert a blank line before “Related Concepts” and after the H2.
- **[Architecture](./architecture.md)** - Learn about Exosphere's architecture - **[State Manager Setup](./state-manager-setup.md)** - Complete backend setup guide - -## Related Concepts + +## Related Concepts + - **[Fanout](./fanout.md)** - Create parallel execution paths dynamically - **[Unite](./unite.md)** - Synchronize parallel execution paths - **[Retry Policy](./retry-policy.md)** - Build resilient workflows - **[Store](./store.md)** - Persist data across workflow executiondocs/docs/exosphere/state-manager-setup.md (1)
242-254: Fix section structure: “Graph Creation” is incorrectly nested under “Related Concepts”After adding a new H2 (“Related Concepts”), the “Graph Creation” bullet now falls inside that section. Move it back under “Next Steps” and add spacing before the new H2.
## Next Steps - **[Dashboard Setup](./dashboard.md)** - Set up the web dashboard for monitoring - **[Node Development](./register-node.md)** - Learn how to create and register nodes +- **[Graph Creation](./create-graph.md)** - Build workflows using graph templates - -## Related Concepts + +## Related Concepts + - **[Fanout](./fanout.md)** - Create parallel execution paths dynamically - **[Unite](./unite.md)** - Synchronize parallel execution paths - **[Retry Policy](./retry-policy.md)** - Build resilient workflows - **[Store](./store.md)** - Persist data across workflow execution -- **[Graph Creation](./create-graph.md)** - Build workflows using graph templatesdocs/docs/docker-compose-setup.md (1)
270-279: Blockquote formatting: keep the marker but remove the orphaned ‘>’ line if not needed.If the intent was a continued blockquote, keep as-is; otherwise drop the empty marker to avoid odd spacing in some themes.
->docs/docs/exosphere/create-runtime.md (1)
61-69: Advanced example uses undefined variables; read from env or define them.
EXOSPHERE_STATE_MANAGER_URIandEXOSPHERE_API_KEYare referenced but never defined in the snippet. Suggest usingos.getenv(...)inline to make the example self-contained.- runtime = Runtime( + import os + runtime = Runtime( namespace="MyProject", name="MyRuntime", nodes=[MyNode], - state_manager_uri=EXOSPHERE_STATE_MANAGER_URI, - key=EXOSPHERE_API_KEY, + state_manager_uri=os.getenv("EXOSPHERE_STATE_MANAGER_URI"), + key=os.getenv("EXOSPHERE_API_KEY"), batch_size=32, workers=8, poll_interval=2 )docs/docs/exosphere/signals.md (4)
36-52: Add missing imports for BaseNode/BaseModel in PruneSignal example.Without these, the snippet won’t run as-is.
-```python hl_lines="13" -from exospherehost import PruneSignal +```python hl_lines="15" +from exospherehost import PruneSignal, BaseNode +from pydantic import BaseModel
64-82: Type error: comparing str to int in ReQueueAfterSignal example.
retry_countis declaredstrbut compared to3. Useint.-```python hl_lines="15" +```python hl_lines="15" from exospherehost import ReQueueAfterSignal from datetime import timedelta +from exospherehost import BaseNode +from pydantic import BaseModel @@ class RetryNode(BaseNode): class Inputs(BaseModel): - retry_count: str + retry_count: int data: str @@ async def execute(self, inputs: Inputs) -> Outputs: - if inputs.retry_count < 3: + if inputs.retry_count < 3: # Requeue after 5 minutes raise ReQueueAfterSignal(timedelta(minutes=5))
106-121: Complete the example: define Outputs and import datetime.The snippet returns
self.Outputs(...)butOutputsisn’t defined; alsodatetimeis used but not imported.-```python hl_lines="7-12" +```python hl_lines="7-12" +from datetime import datetime +from exospherehost import BaseNode +from pydantic import BaseModel class ValidationNode(BaseNode): class Inputs(BaseModel): user_id: str data: dict + class Outputs(BaseModel): + validated: bool
125-140: Add missing timedelta import in Polling example.Keep snippets self-contained.
-```python hl_lines="14" +```python hl_lines="14" +from datetime import timedeltadocs/docs/exosphere/architecture.md (1)
3-3: Align overview with current content focus.Intro still says it focuses on fanout/unites; the page now emphasizes runtime interaction and execution flow.
-This document provides a comprehensive overview of Exosphere's top-level architecture, focusing on state execution, fanout mechanisms, and the unites keyword for stage unification. +This document provides a comprehensive overview of Exosphere's top-level architecture, focusing on the state execution model and runtime interaction with the state manager.docs/docs/exosphere/retry-policy.md (4)
223-227: Fix_capexample: usesselfin a free function.Make it standalone or show it as a method. Standalone version:
-def _cap(value: int) -> int: - if self.max_delay is not None: - return min(value, self.max_delay) - return value +def _cap(max_delay: int | None, value: int) -> int: + return min(value, max_delay) if max_delay is not None else value
337-346: Tighten wording on retry preconditions.“State status is QUEUED” is ambiguous. Suggest clarifying that a new retry state is created and queued, while the failed state is marked ERRORED.
-Retries are automatically triggered when: +Retries are automatically triggered when: @@ -3. The state status is `QUEUED` +3. A new retry state is created and set to `QUEUED`
389-425: Minor formatting: add blank lines around headings and code blocks.Insert a blank line after “## Model-Based Configuration” and before/after fenced blocks to satisfy MD022/MD032.
Also applies to: 434-475
355-367: Consider adding guidance on Retry-After headers and idempotency.Brief note that callers should respect 429/Retry-After and ensure node actions are idempotent on retries would improve operational safety.
docs/docs/getting-started.md (1)
160-176: Avoid using a private method in docs (runtime._start()).Prefer running the blocking
start()in a thread for async contexts:-# In Jupyter notebooks or async contexts, use asyncio.create_task -# to run the runtime in the background -runtime_task = asyncio.create_task(runtime._start()) +# In async contexts, offload the blocking start() to a thread +loop = asyncio.get_running_loop() +runtime_task = loop.run_in_executor(None, runtime.start)docs/docs/exosphere/create-graph.md (1)
3-90: General spacing/markdownlint cleanup.There are a few “Use correct spacing” and MD009 (trailing spaces) warnings flagged by tooling (e.g., Line 12). Ensure a single blank line before/after headings and code fences, and strip trailing spaces.
| ## Next Steps | ||
|
|
||
| Now that your Exosphere services are running, continue with these guides: | ||
|
|
||
| - **[Create a Node](./exosphere/register-node.md)** – Learn how to define and register your own node. | ||
| - **[Create a Runtime](./exosphere/create-runtime.md)** – Set up and configure your runtime environment. | ||
| - **[Create a Graph](./exosphere/create-graph.md)** – Build workflows by connecting nodes together. | ||
| - **[Trigger a Graph](./exosphere/trigger-graph.md)** – Execute your workflows and monitor their progress. | ||
|
|
||
|
|
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Nice “Next Steps” block; minor copy polish.
Consider consistent capitalization for MongoDB elsewhere (“MongoDB” vs “Mongodb”) and vary sentence starts (“Create …”) for style, but content LGTM.
🧰 Tools
🪛 LanguageTool
[grammar] ~122-~122: Use correct spacing
Context: ...tp://localhost:8000/docs` ## Next Steps Now that your Exosphere services are run...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~124-~124: Use correct spacing
Context: ...are running, continue with these guides: - **[Create a Node](./exosphere/register-node...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~126-~126: Make sure you are using the right part of speech
Context: ...e with these guides: - Create a Node – Learn how to define and register your own nod...
(QB_NEW_EN_OTHER_ERROR_IDS_21)
[grammar] ~126-~126: There might be a mistake here.
Context: ...ow to define and register your own node. - **[Create a Runtime](./exosphere/create-run...
(QB_NEW_EN)
[style] ~128-~128: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...onfigure your runtime environment. - Create a Graph...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[grammar] ~128-~128: There might be a mistake here.
Context: ...runtime environment. - Create a Graph – Build workflows by connecting nodes together....
(QB_NEW_EN_OTHER)
[grammar] ~128-~128: There might be a mistake here.
Context: ... workflows by connecting nodes together. - **[Trigger a Graph](./exosphere/trigger-gra...
(QB_NEW_EN)
[grammar] ~129-~129: Make sure you are using the right part of speech
Context: ...ing nodes together. - Trigger a Graph – Execute your workflows and monitor their progre...
(QB_NEW_EN_OTHER_ERROR_IDS_21)
[grammar] ~129-~129: Use correct spacing
Context: ...ur workflows and monitor their progress. ## Development Commands === "Cloud Mongodb...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
🤖 Prompt for AI Agents
In docs/docs/docker-compose-setup.md around lines 122 to 131, the "Next Steps"
block needs minor copy polishing: ensure consistent capitalization for MongoDB
across the docs (use "MongoDB" not "Mongodb") and vary the sentence starters in
the bullet list (avoid repeating "Create ...") by rewording some items to use
alternative verbs or phrasings while keeping links and targets unchanged.
| 4. **ERRORED**: State failed during executionState and all its dependencies are complete | ||
| 5. **SUCCESS**: Workflow/branch-level success once all dependent states complete | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
Fix sentence and clarity in lifecycle bullets.
Grammar issue (“executionState”) and unclear SUCCESS description.
-3. **EXECUTED**: State finished (with outputs) — terminal for that state
-4. **ERRORED**: State failed during executionState and all its dependencies are complete
-5. **SUCCESS**: Workflow/branch-level success once all dependent states complete
+3. **EXECUTED**: State finished (with outputs) — terminal for that state
+4. **ERRORED**: State failed during execution
+5. **SUCCESS**: Workflow/branch-level success once all dependent states complete📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| 4. **ERRORED**: State failed during executionState and all its dependencies are complete | |
| 5. **SUCCESS**: Workflow/branch-level success once all dependent states complete | |
| 3. **EXECUTED**: State finished (with outputs) — terminal for that state | |
| 4. **ERRORED**: State failed during execution | |
| 5. **SUCCESS**: Workflow/branch-level success once all dependent states complete |
🧰 Tools
🪛 LanguageTool
[grammar] ~31-~31: There might be a mistake here.
Context: ...ate 4. ERRORED: State failed during executionState and all its dependencies are complete 5...
(QB_NEW_EN_OTHER)
[grammar] ~31-~31: There might be a mistake here.
Context: ...te and all its dependencies are complete 5. SUCCESS: Workflow/branch-level success...
(QB_NEW_EN_OTHER)
[grammar] ~32-~32: There might be a mistake here.
Context: ...ccess once all dependent states complete ### State Execution Flow The following diag...
(QB_NEW_EN_OTHER)
🤖 Prompt for AI Agents
In docs/docs/exosphere/architecture.md around lines 31 to 33, fix the lifecycle
bullet wording: change “executionState” to “execution state” in the ERRORED line
and rewrite the SUCCESS line to be clear and grammatical (e.g., “SUCCESS:
Workflow- or branch-level success when all dependent states have completed
successfully” or “SUCCESS: Workflow/branch-level success once all states in the
workflow or branch have completed”); update both bullets for consistent
punctuation and clarity.
| - **[Fanout](./fanout.md)** - Learn about parallel execution and dynamic scaling | ||
| - **[Unite](./unite.md)** - Understand synchronization of parallel paths | ||
| - **[Signals](./signals.md)** - Control workflow execution flow | ||
| - **[Retry Policy](./retry-policy.md)** - Build resilient workflows |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Ensure file ends with a newline.
Fixes MD047.
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
113-113: Files should end with a single newline character
(MD047, single-trailing-newline)
🤖 Prompt for AI Agents
In docs/docs/exosphere/architecture.md at line 113, the file is missing a
trailing newline which triggers MD047; add a single newline character at the end
of the file so the last line ends with a newline (ensure the file terminates
with '\n').
| ### 1. **State-Based Execution Model** | ||
| - **Discrete States**: Each workflow step is a separate, independently executable state | ||
| - **Persistent State**: All states are stored in the database for reliability and recovery | ||
| - **Independent Execution**: States can be processed by any available runtime instance | ||
|
|
||
| ### 2. **Dynamic Fanout** | ||
| - **Runtime Fanout**: Nodes can produce multiple outputs during execution, creating parallel paths | ||
| - **Variable Parallelism**: The number of parallel executions is determined at runtime, not design time | ||
| - **Automatic Scaling**: More runtime instances automatically handle increased parallel load | ||
|
|
||
| ### 3. **Intelligent Unite** | ||
| - **Smart Synchronization**: The `unites` keyword synchronizes parallel execution paths | ||
| - **State Fingerprinting**: Prevents duplicate unite states for the same parallel branch | ||
| - **Flexible Strategies**: Choose between waiting for all success or all completion | ||
|
|
||
| ### 4. **Signals System** | ||
| - **Flow Control**: Nodes can control workflow execution by raising signals | ||
| - **Prune Signal**: Terminate execution branches when conditions aren't met | ||
| - **ReQueue Signal**: Schedule retries or polling with custom delays | ||
|
|
||
| ### 5. **Advanced Retry Policies** | ||
| - **Multiple Strategies**: Exponential, linear, and fixed backoff with jitter variants | ||
| - **Jitter Prevention**: Built-in jitter prevents thundering herd problems | ||
| - **Delay Capping**: Configurable maximum delays for predictable behavior | ||
|
|
||
| ### 6. **Persistent Store** | ||
| - **Graph-Level Storage**: Key-value store that persists across the entire workflow execution | ||
| - **Runtime Access**: All nodes can read and write to the shared store | ||
| - **Automatic Cleanup**: Store data is automatically cleaned up when workflows complete | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Insert blank lines after subheadings before bullet lists for readability
Each “###” heading should be followed by a blank line to satisfy common linters and improve rendering.
-### 1. **State-Based Execution Model**
+### 1. **State-Based Execution Model**
+
- **Discrete States**: Each workflow step is a separate, independently executable state
...
-### 2. **Dynamic Fanout**
+### 2. **Dynamic Fanout**
+
- **Runtime Fanout**: Nodes can produce multiple outputs during execution, creating parallel paths
...
-### 3. **Intelligent Unite**
+### 3. **Intelligent Unite**
+
- **Smart Synchronization**: The `unites` keyword synchronizes parallel execution paths
...
-### 4. **Signals System**
+### 4. **Signals System**
+
- **Flow Control**: Nodes can control workflow execution by raising signals
...
-### 5. **Advanced Retry Policies**
+### 5. **Advanced Retry Policies**
+
- **Multiple Strategies**: Exponential, linear, and fixed backoff with jitter variants
...
-### 6. **Persistent Store**
+### 6. **Persistent Store**
+
- **Graph-Level Storage**: Key-value store that persists across the entire workflow execution📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ### 1. **State-Based Execution Model** | |
| - **Discrete States**: Each workflow step is a separate, independently executable state | |
| - **Persistent State**: All states are stored in the database for reliability and recovery | |
| - **Independent Execution**: States can be processed by any available runtime instance | |
| ### 2. **Dynamic Fanout** | |
| - **Runtime Fanout**: Nodes can produce multiple outputs during execution, creating parallel paths | |
| - **Variable Parallelism**: The number of parallel executions is determined at runtime, not design time | |
| - **Automatic Scaling**: More runtime instances automatically handle increased parallel load | |
| ### 3. **Intelligent Unite** | |
| - **Smart Synchronization**: The `unites` keyword synchronizes parallel execution paths | |
| - **State Fingerprinting**: Prevents duplicate unite states for the same parallel branch | |
| - **Flexible Strategies**: Choose between waiting for all success or all completion | |
| ### 4. **Signals System** | |
| - **Flow Control**: Nodes can control workflow execution by raising signals | |
| - **Prune Signal**: Terminate execution branches when conditions aren't met | |
| - **ReQueue Signal**: Schedule retries or polling with custom delays | |
| ### 5. **Advanced Retry Policies** | |
| - **Multiple Strategies**: Exponential, linear, and fixed backoff with jitter variants | |
| - **Jitter Prevention**: Built-in jitter prevents thundering herd problems | |
| - **Delay Capping**: Configurable maximum delays for predictable behavior | |
| ### 6. **Persistent Store** | |
| - **Graph-Level Storage**: Key-value store that persists across the entire workflow execution | |
| - **Runtime Access**: All nodes can read and write to the shared store | |
| - **Automatic Cleanup**: Store data is automatically cleaned up when workflows complete | |
| ### 1. **State-Based Execution Model** | |
| - **Discrete States**: Each workflow step is a separate, independently executable state | |
| - **Persistent State**: All states are stored in the database for reliability and recovery | |
| - **Independent Execution**: States can be processed by any available runtime instance | |
| ### 2. **Dynamic Fanout** | |
| - **Runtime Fanout**: Nodes can produce multiple outputs during execution, creating parallel paths | |
| - **Variable Parallelism**: The number of parallel executions is determined at runtime, not design time | |
| - **Automatic Scaling**: More runtime instances automatically handle increased parallel load | |
| ### 3. **Intelligent Unite** | |
| - **Smart Synchronization**: The `unites` keyword synchronizes parallel execution paths | |
| - **State Fingerprinting**: Prevents duplicate unite states for the same parallel branch | |
| - **Flexible Strategies**: Choose between waiting for all success or all completion | |
| ### 4. **Signals System** | |
| - **Flow Control**: Nodes can control workflow execution by raising signals | |
| - **Prune Signal**: Terminate execution branches when conditions aren't met | |
| - **ReQueue Signal**: Schedule retries or polling with custom delays | |
| ### 5. **Advanced Retry Policies** | |
| - **Multiple Strategies**: Exponential, linear, and fixed backoff with jitter variants | |
| - **Jitter Prevention**: Built-in jitter prevents thundering herd problems | |
| - **Delay Capping**: Configurable maximum delays for predictable behavior | |
| ### 6. **Persistent Store** | |
| - **Graph-Level Storage**: Key-value store that persists across the entire workflow execution | |
| - **Runtime Access**: All nodes can read and write to the shared store | |
| - **Automatic Cleanup**: Store data is automatically cleaned up when workflows complete |
🧰 Tools
🪛 LanguageTool
[grammar] ~26-~26: There might be a mistake here.
Context: ...es ### 1. State-Based Execution Model - Discrete States: Each workflow step is...
(QB_NEW_EN)
[grammar] ~27-~27: There might be a mistake here.
Context: ...separate, independently executable state - Persistent State: All states are store...
(QB_NEW_EN_OTHER)
[grammar] ~28-~28: There might be a mistake here.
Context: ...he database for reliability and recovery - Independent Execution: States can be p...
(QB_NEW_EN_OTHER)
[grammar] ~29-~29: There might be a mistake here.
Context: ...cessed by any available runtime instance ### 2. Dynamic Fanout - **Runtime Fanout...
(QB_NEW_EN_OTHER)
[grammar] ~31-~31: There might be a mistake here.
Context: ...untime instance ### 2. Dynamic Fanout - Runtime Fanout: Nodes can produce mult...
(QB_NEW_EN)
[grammar] ~32-~32: There might be a mistake here.
Context: ...uring execution, creating parallel paths - Variable Parallelism: The number of pa...
(QB_NEW_EN_OTHER)
[grammar] ~33-~33: There might be a mistake here.
Context: ...s determined at runtime, not design time - Automatic Scaling: More runtime instan...
(QB_NEW_EN_OTHER)
[grammar] ~34-~34: There might be a mistake here.
Context: ...matically handle increased parallel load ### 3. Intelligent Unite - **Smart Synch...
(QB_NEW_EN_OTHER)
[grammar] ~36-~36: There might be a mistake here.
Context: ...sed parallel load ### 3. Intelligent Unite - Smart Synchronization: The unites ke...
(QB_NEW_EN_OTHER)
[grammar] ~37-~37: There might be a mistake here.
Context: ...rd synchronizes parallel execution paths - State Fingerprinting: Prevents duplica...
(QB_NEW_EN_OTHER)
[grammar] ~38-~38: There might be a mistake here.
Context: ...nite states for the same parallel branch - Flexible Strategies: Choose between wa...
(QB_NEW_EN_OTHER)
[grammar] ~39-~39: There might be a mistake here.
Context: ...aiting for all success or all completion ### 4. Signals System - Flow Control...
(QB_NEW_EN_OTHER)
[grammar] ~41-~41: There might be a mistake here.
Context: ... all completion ### 4. Signals System - Flow Control: Nodes can control workfl...
(QB_NEW_EN)
[grammar] ~42-~42: There might be a mistake here.
Context: ...ol workflow execution by raising signals - Prune Signal: Terminate execution bran...
(QB_NEW_EN_OTHER)
[grammar] ~43-~43: There might be a mistake here.
Context: ...tion branches when conditions aren't met - ReQueue Signal: Schedule retries or po...
(QB_NEW_EN_OTHER)
[grammar] ~44-~44: There might be a mistake here.
Context: ...le retries or polling with custom delays ### 5. Advanced Retry Policies - **Multi...
(QB_NEW_EN_OTHER)
[grammar] ~46-~46: There might be a mistake here.
Context: ...delays ### 5. Advanced Retry Policies - Multiple Strategies: Exponential, line...
(QB_NEW_EN)
[grammar] ~47-~47: There might be a mistake here.
Context: ..., and fixed backoff with jitter variants - Jitter Prevention: Built-in jitter pre...
(QB_NEW_EN)
[grammar] ~48-~48: There might be a mistake here.
Context: ...jitter prevents thundering herd problems - Delay Capping: Configurable maximum de...
(QB_NEW_EN)
[grammar] ~49-~49: Use correct spacing
Context: ... maximum delays for predictable behavior ### 6. Persistent Store - **Graph-Level ...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~51-~51: There might be a mistake here.
Context: ...able behavior ### 6. Persistent Store - Graph-Level Storage: Key-value store t...
(QB_NEW_EN)
[grammar] ~52-~52: There might be a mistake here.
Context: ...sts across the entire workflow execution - Runtime Access: All nodes can read and...
(QB_NEW_EN)
[grammar] ~53-~53: There might be a mistake here.
Context: ...s can read and write to the shared store - Automatic Cleanup: Store data is autom...
(QB_NEW_EN)
[grammar] ~54-~54: Use correct spacing
Context: ...cally cleaned up when workflows complete ## How They Work Together These concepts c...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
🤖 Prompt for AI Agents
docs/docs/exosphere/concepts.md around lines 26 to 55: the section headings use
"###" subheadings that are immediately followed by bullet lists, which fails
common linters and reduces readability; insert a single blank line after each
"###" heading (e.g., between "### 1. **State-Based Execution Model**" and its
first bullet) across the listed blocks so every subheading is followed by one
empty line before its corresponding list or paragraph.
No description provided.