Conversation
Add TestnetBradbury as a new network option across all developer-facing docs while keeping TestnetAsimov for infrastructure/stress testing. Examples default to Bradbury; both networks listed as options with Asimov first. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
✅ Deploy Preview for genlayer-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThis PR adds a new testnet "testnet-bradbury" (camelCase: Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
pages/developers/intelligent-contracts/deploying/network-configuration.mdx (1)
157-164:⚠️ Potential issue | 🟠 MajorUpdate examples to use the correct
genlayer network setsyntax.The official CLI reference (
pages/api-references/genlayer-cli.mdx) documentsgenlayer network set [network]as the only supported form for selecting a network. The examples here usegenlayer network <network>directly, which is not a supported syntax and will fail when users run these commands. Update all examples to usegenlayer network set localnet,genlayer network set testnet-bradbury, etc.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@pages/developers/intelligent-contracts/deploying/network-configuration.mdx` around lines 157 - 164, The examples in the "Direct Network Selection" block use the unsupported command form "genlayer network <network>"; update those lines to the documented "genlayer network set <network>" form (e.g., change occurrences like genlayer network localnet to genlayer network set localnet and similarly for studionet, testnet-asimov, testnet-bradbury) so the examples match the official CLI reference documented in genlayer-cli.mdx and will work when users run genlayer network set from the CLI.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@pages/developers/intelligent-contracts/deploying/deploy-scripts.mdx`:
- Around line 69-73: The receipt field selection is inverted: per GenLayerJS,
Bradbury uses receipt.data.contract_address and Asimov uses
receipt.txDataDecoded.contractAddress; replace the chain-specific check in the
deployedContractAddress assignment (and the other occurrences around the file)
with a feature-detect that prefers receipt.data.contract_address when present
and falls back to (receipt.txDataDecoded as DecodedDeployData)?.contractAddress
otherwise — update the logic that references client.chain / GenLayerChain /
testnetBradbury and the fields receipt.data.contract_address and
receipt.txDataDecoded.contractAddress accordingly.
In `@pages/developers/intelligent-contracts/deploying/network-configuration.mdx`:
- Around line 76-89: The "TestnetBradbury" section is contradictory—it says
config details are forthcoming yet simultaneously instructs users to switch to
`testnet-bradbury`, get faucet funds, and treat Bradbury as a recommended
deployment target; update the copy so it’s consistent by either (A) marking all
Bradbury-specific commands/workflows and the Callout as "preview/coming soon"
and removing any live deployment instructions, or (B) removing Bradbury live
guidance entirely and pointing users to continue using Testnet Asimov until
Bradbury addresses are published; ensure you update the "TestnetBradbury"
header, the Callout block, and the other Bradbury mentions in the same page to
reflect the chosen approach.
In `@pages/validators/setup-guide.mdx`:
- Around line 128-129: The guide currently lists "testnet-bradbury" alongside
"testnet-asimov" while the sample node config shows only a single consensus
address/genesis pair valid for Asimov, which is misleading; update the "Network
selection" options and sample config so validators are not routed to Bradbury
until its consensus address and genesis are published: either remove
"testnet-bradbury" from the network selection and any Bradbury mentions in the
sample node config (the consensus address/genesis pair block), or add a separate
Bradbury config block with the proper consensus address and genesis once
available; ensure the "Balance verification" text remains accurate for
Asimov-only flows and mirror the same change where the guide repeats this
guidance (the other referenced sample config block).
---
Outside diff comments:
In `@pages/developers/intelligent-contracts/deploying/network-configuration.mdx`:
- Around line 157-164: The examples in the "Direct Network Selection" block use
the unsupported command form "genlayer network <network>"; update those lines to
the documented "genlayer network set <network>" form (e.g., change occurrences
like genlayer network localnet to genlayer network set localnet and similarly
for studionet, testnet-asimov, testnet-bradbury) so the examples match the
official CLI reference documented in genlayer-cli.mdx and will work when users
run genlayer network set from the CLI.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 0559da82-db56-4965-b51f-38625b208b86
📒 Files selected for processing (8)
pages/api-references/genlayer-cli.mdxpages/api-references/genlayer-js.mdxpages/api-references/genlayer-test.mdxpages/developers/intelligent-contracts/deploying.mdxpages/developers/intelligent-contracts/deploying/cli-deployment.mdxpages/developers/intelligent-contracts/deploying/deploy-scripts.mdxpages/developers/intelligent-contracts/deploying/network-configuration.mdxpages/validators/setup-guide.mdx
| // Receipt structure differs between testnet and localnet/studionet | ||
| const deployedContractAddress = | ||
| (client.chain as GenLayerChain).id !== testnetAsimov.id | ||
| (client.chain as GenLayerChain).id !== testnetBradbury.id | ||
| ? receipt.data.contract_address | ||
| : (receipt.txDataDecoded as DecodedDeployData)?.contractAddress; |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
In the current GenLayerJS docs or source, when deploying on testnetAsimovandtestnetBradbury, which receipt field contains the deployed contract address? Is txDataDecoded.contractAddress used for both testnets, or only for Bradbury?
💡 Result:
testnetBradbury: the deployed contract address is inreceipt.data.contract_address(same as localnet/studionet). (docs.genlayer.com)testnetAsimov: the deployed contract address is in(receipt.txDataDecoded as DecodedDeployData).contractAddress. (docs.genlayer.com)
So txDataDecoded.contractAddress is not used for Bradbury in the current GenLayerJS docs—it’s used for Asimov only. (docs.genlayer.com)
Citations:
- 1: https://docs.genlayer.com/api-references/genlayer-js?utm_source=openai
- 2: https://docs.genlayer.com/developers/intelligent-contracts/deploying/deploy-scripts?utm_source=openai
- 3: https://docs.genlayer.com/developers/intelligent-contracts/deploying/deploy-scripts?utm_source=openai
Fix inverted receipt field logic affecting both testnet deployments.
The code branches only on testnetBradbury but has the condition logic inverted: it reads receipt.data.contract_address for Asimov and txDataDecoded.contractAddress for Bradbury. According to GenLayerJS docs, the fields are swapped—Asimov uses txDataDecoded.contractAddress while Bradbury uses receipt.data.contract_address. This causes Asimov deployments to read the wrong field, resulting in missing or incorrect contract addresses.
Use a feature-detect approach instead of chain-specific branching:
♻️ Suggested fix
- // Receipt structure differs between testnet and localnet/studionet
- const deployedContractAddress =
- (client.chain as GenLayerChain).id !== testnetBradbury.id
- ? receipt.data.contract_address
- : (receipt.txDataDecoded as DecodedDeployData)?.contractAddress;
+ // Prefer the decoded deploy payload when present; fall back to the legacy field.
+ const deployedContractAddress =
+ (receipt.txDataDecoded as DecodedDeployData | undefined)?.contractAddress ??
+ receipt.data?.contract_address;
+
+ if (!deployedContractAddress) {
+ throw new Error("Deployment succeeded but no contract address was returned in the receipt");
+ }Also applies to: 153-157, 237-241
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@pages/developers/intelligent-contracts/deploying/deploy-scripts.mdx` around
lines 69 - 73, The receipt field selection is inverted: per GenLayerJS, Bradbury
uses receipt.data.contract_address and Asimov uses
receipt.txDataDecoded.contractAddress; replace the chain-specific check in the
deployedContractAddress assignment (and the other occurrences around the file)
with a feature-detect that prefers receipt.data.contract_address when present
and falls back to (receipt.txDataDecoded as DecodedDeployData)?.contractAddress
otherwise — update the logic that references client.chain / GenLayerChain /
testnetBradbury and the fields receipt.data.contract_address and
receipt.txDataDecoded.contractAddress accordingly.
| ## TestnetBradbury | ||
|
|
||
| **Purpose**: Production-like testing environment with real AI/LLM use cases | ||
| - **When to use**: For deploying and testing intelligent contracts with real LLM models | ||
| - **Setup**: Connect using network configuration | ||
| - **Benefits**: | ||
| - Real AI workloads using powerful LLM models | ||
| - Production-like environment for intelligent contract testing | ||
| - Real use cases and contracts deployed | ||
| - Shared testnet for community testing | ||
|
|
||
| <Callout emoji="ℹ️"> | ||
| Testnet Bradbury configuration details will be available when the network goes live. The faucet and RPC endpoints are shared with Testnet Asimov. | ||
| </Callout> |
There was a problem hiding this comment.
Separate Bradbury preview copy from live deployment guidance.
This section says Bradbury config details will only be available once the network goes live, but the same page immediately tells users to switch to testnet-bradbury, grab faucet funds, and use Bradbury as the recommended final deployment target. That reads as both “coming soon” and “ready now.” Either label these commands/workflow steps as preview-only, or keep the live guidance on Asimov until Bradbury addresses are published.
Also applies to: 93-103, 120-123
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@pages/developers/intelligent-contracts/deploying/network-configuration.mdx`
around lines 76 - 89, The "TestnetBradbury" section is contradictory—it says
config details are forthcoming yet simultaneously instructs users to switch to
`testnet-bradbury`, get faucet funds, and treat Bradbury as a recommended
deployment target; update the copy so it’s consistent by either (A) marking all
Bradbury-specific commands/workflows and the Callout as "preview/coming soon"
and removing any live deployment instructions, or (B) removing Bradbury live
guidance entirely and pointing users to continue using Testnet Asimov until
Bradbury addresses are published; ensure you update the "TestnetBradbury"
header, the Callout block, and the other Bradbury mentions in the same page to
reflect the chosen approach.
| genlayer network set # Interactive selection menu | ||
| genlayer network set localnet # Set network to localnet | ||
| genlayer network set testnet-asimov # Set network to testnet-asimov | ||
| genlayer network set testnet-bradbury # Set network to testnet-bradbury |
There was a problem hiding this comment.
Should we have both options here? I am afraid that not having both always will try bradbury
pages/validators/setup-guide.mdx
Outdated
| # consensus contracts configuration | ||
| consensus: | ||
| # Testnet - Phase 5 | ||
| # Testnet Asimov or Bradbury consensus contract |
There was a problem hiding this comment.
Here we will always leave pointing to Testnet Asimov. On top of this I think is where we going to mention this
The goal of asimov is to test the stability of the consensus mechanism, stability and scalability in all the edge cases. The goal of Bradbury is to is to bring the large language models into the mix. Twofold for the validators themselves to start testing and optimizing their own large language model setup and for application developers to test their applications against the realistic decentralized multi-validated multi-large language model environment
There was a problem hiding this comment.
ok, let's leave asimov!
- Add both testnet-asimov and testnet-bradbury examples in CLI reference - Keep validators defaulting to testnet-asimov - Add Bradbury consensus contract address as commented-out alternative Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
3 participants
Summary
Test plan
pnpm buildsucceedstestnetBradburyimports🤖 Generated with Claude Code
Summary by CodeRabbit