Conversation
Greptile SummaryThis PR adds a Safe Deployment Practices section to the Block-STM documentation, covering three important deployment considerations for teams integrating parallel execution: phased rollout strategy, message type validation requirements (including a CosmWasm caveat), and caching/indeterminism risks.\n\nThe content is technically sound and provides genuinely useful operational guidance. A few minor formatting issues are worth cleaning up before merge:\n\n- An accidental line break leaves the word "extensive" orphaned on its own line in the introductory sentence.\n- The three sub-topic bullet points ( Confidence Score: 4/5Documentation-only PR that is safe to merge; minor formatting fixes recommended but not blocking. The new section adds valuable operational guidance with accurate technical content. No code is changed. The three style/formatting issues identified (orphaned line break, unindented bullet content, sdk/next/experimental/blockstm.mdx — minor formatting cleanup in the new Safe Deployment Practices section Important Files Changed
Reviews (1): Last reviewed commit: "More updates" | Re-trigger Greptile |
| Given the Block-STM executor is a general purpose parallel execution engine, we recommend a phased rollout with | ||
| extensive | ||
| testing for each application individually. |
There was a problem hiding this comment.
Accidental line break splits intro sentence
The word extensive is orphaned on its own line, which appears to be an editing artifact. While most Markdown renderers will collapse this into a single space, it reads awkwardly in source and could confuse future editors.
| Given the Block-STM executor is a general purpose parallel execution engine, we recommend a phased rollout with | |
| extensive | |
| testing for each application individually. | |
| Given the Block-STM executor is a general-purpose parallel execution engine, we recommend a phased rollout with extensive testing for each application individually. |
(Also note: "general-purpose" should be hyphenated when used as a compound modifier before a noun.)
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
| * _Phased Rollout_ | ||
|
|
||
| Since parallel execution is purely a performance optimization, applications should expect to calculate the same | ||
| AppHash when using Block-STM as they would when serial execution is enabled via the default TxRunner. This allows teams | ||
| to turn on parallel execution for a fraction of their nodes--API nodes instead of validators or on a portion of a | ||
| distributed validator cluster for example. | ||
|
|
||
| Running with a mixed fleet of parallel and serial execution for an extended time should minimize blast radius in the | ||
| event that a failure occurs. | ||
|
|
||
| * _Message Type Support_ | ||
|
|
||
| We have done testing on as many of the core SDK message types as possible, but given the Cosmos SDK allows arbitrary | ||
| message creation it will be impossible to validate all message types that exist and all combinations of workflows. | ||
| Each team integrating Block-STM in production should validate their own message types for both correctness and performance. | ||
|
|
||
| NOTE: We specifically have __not__ validated support for CosmWasm message types run using Block-STM. Run independent | ||
| validation before enabling if your chain uses CosmWasm. | ||
|
|
||
| * _Caching Risks_ | ||
|
|
||
| Block-STM works via dependency tracking within the SDK's `MultiStore` interface. Any data which could cause stateful | ||
| changes to execution that lives outside the store poses the biggest risk for indeterminism. We recommend in general | ||
| avoiding the use of cached data, in memory stores, or persisting any state outside the scope of a `Store`. |
There was a problem hiding this comment.
Bullet content not indented under list items
In Markdown/MDX, a blank line after a list item followed by non-indented text breaks the association — the paragraphs render as standalone text outside the list rather than as continuations of each bullet. This means readers may not visually connect each heading (_Phased Rollout_, _Message Type Support_, _Caching Risks_) with its explanatory paragraph.
To keep content inside the list item, indent the paragraphs with at least two spaces:
* _Phased Rollout_
Since parallel execution is purely a performance optimization, applications should expect to calculate the same
AppHash when using Block-STM as they would when serial execution is enabled via the default TxRunner. ...
* _Message Type Support_
We have done testing on as many of the core SDK message types as possible, ...
* _Caching Risks_
Block-STM works via dependency tracking within the SDK's `MultiStore` interface. ...
Alternatively, use ### subheadings instead of italic bullets for each sub-topic, which is more consistent with the rest of the document's structure.
| message creation it will be impossible to validate all message types that exist and all combinations of workflows. | ||
| Each team integrating Block-STM in production should validate their own message types for both correctness and performance. | ||
|
|
||
| NOTE: We specifically have __not__ validated support for CosmWasm message types run using Block-STM. Run independent |
There was a problem hiding this comment.
Use
** for emphasis instead of __
Double-underscores for bold (__not__) can behave inconsistently in some MDX parsers, particularly when surrounded by non-whitespace characters. The ** syntax is more portable and consistent with the rest of the document.
| NOTE: We specifically have __not__ validated support for CosmWasm message types run using Block-STM. Run independent | |
| NOTE: We specifically have **not** validated support for CosmWasm message types run using Block-STM. Run independent |
|
Preview deployment for your docs. Learn more about Mintlify Previews.
|
|
LGTM. Merge away! |
Adds a section for deployment practices and risks to look out for when integrating parallel execution.