Rill

Core backend integrations for transaction simulation, flow publishing, and protocol introspection are unreliable, routinely failing after a long stall.

Testing covered 11 scenarios spanning wallet connection, canvas template loading, graph layout, navigation, protocol introspection, PTB flow simulation, and code compilation and export.

Three primary features were confirmed unreliable against Rill's own backend (api.rill.naisu.one): the PTB flow dry-run simulation, publishing a flow, and protocol introspection. All three were reproduced by hand in a real browser: each stalls for roughly 15 to 20 seconds and then fails with the same generic "Rill API didn't respond in time — try again" message, rather than hanging forever with no feedback as the original scenario runs recorded. The underlying failures are real, just not silent or infinite.

Network connection limits in the test environment prevented backend communication during protocol input validation, action filtering, search empty states, and capabilities configuration, though basic interface behaviors passed. With simulation, publishing, and introspection all failing against the live backend, the primary workflow tools are currently unreliable to the point of being unusable.

Target: https://rill.naisu.one/ · Testing level: deep_feature · Stack: unknown

Severity: high · Type: functional · Verdict: confirmed · Scenario: S3

I navigated to /builder, selected the Swap template, and clicked Simulate. The modal opened but stalled on the text 'devInspect via Rill backend…' without showing gas estimates or balance changes, reproducing the issue exactly as reported. Hand check, 2026-09-27: reproduced the same Cetus swap flow in a real browser. The simulate call stalled on 'devInspect via Rill backend…' for about 18 seconds, then failed with "Rill API didn't respond in time — try again", the same message F3's introspection call surfaces. Not an indefinite hang with zero feedback, but a genuinely unreliable backend call, confirmed.

Expected: The simulation modal opens and displays live PTB devInspect execution results including gas estimates and balance changes promptly.

Actual: The simulation modal opens with 'Live simulation · https://api.rill.naisu.one/api' and stalls on 'devInspect via Rill backend…' well past what a user would wait for, then fails with a generic "Rill API didn't respond in time — try again" message instead of showing gas or balance changes.

Steps to reproduce:

1. Navigate to https://rill.naisu.one/builder
2. Click the 'Template' button and select the 'Swap' template
3. Click the 'Simulate' button in the top action bar

Evidence: screenshots/S3-10.png

Severity: high · Type: functional · Verdict: confirmed · Scenario: S4

The publishing process stalls without error feedback recorded in the run. The live replay was inconclusive: the replay ran out of tool calls before it reached the reported state. Hand check, 2026-09-27: reproduced by hand in a real browser, added a Cetus swap node and clicked Publish. The dialog stalled on 'Publishing flow…' for about 18 seconds, then failed with "Rill API didn't respond in time — try again" and returned to the Review & publish screen with Publish re-enabled. Same backend host and same generic error as F1 and F3, not an indefinite hang with zero feedback, but confirmed unreliable.

Expected: The flow should compile and publish promptly, or display the generated MCP Server code / export snippets.

Actual: The modal stalls on 'Publishing flow… Publishing action metadata and registering the bounded Rill tools.' well past what a user would wait for, then fails with a generic "Rill API didn't respond in time — try again" message and reverts to the review screen, with no exported code.

Steps to reproduce:

1. Navigate to https://rill.naisu.one/builder
2. Click the 'Template' button in the toolbar
3. Select the 'Swap → Stake' template and confirm replacement
4. Click the 'Compile & export' button
5. Click 'Publish' in the Review & publish modal

Evidence: screenshots/S4-8.png

Severity: high · Type: functional · Verdict: confirmed · Scenario: S5

The introspection request stalled on 'Reading ABI…' well past what a user would wait for, and there were no prior console errors to attribute this to the test environment. The live replay was inconclusive: the replay ran out of tool calls before it reached the reported state. Hand check, 2026-09-27: repeated twice against the Sui framework package (0x2) in a real browser. Both attempts stalled on 'Reading ABI…' for about 15 seconds, then the app did surface a message, "Rill API didn't respond in time — try again", so this is not an indefinite hang with zero feedback. The underlying defect is real: introspection of a valid, real testnet package consistently fails against Rill's own backend, it just fails with a delayed, generic retry message rather than hanging forever.

Expected: The application should fetch and parse the on-chain package ABI promptly, or display a clear error message quickly if the package cannot be retrieved.

Actual: The Introspect button transitions to 'Reading ABI…' (disabled) and stalls for an extended period before failing with a generic "API didn't respond in time" message, for a valid, real package ID.

Steps to reproduce:

1. Navigate to https://rill.naisu.one/builder
2. Click 'Discover / Import' in the library sidebar
3. Enter a package ID into the '0x… (the protocol's published package id)' input
4. Click 'Introspect'

Evidence: screenshots/S5-7.png

These failures came from the test environment, not from the application: a credential the sandbox does not hold, a demo nobody may write to, a resource it cannot reach. They are not counted as issues. They record what this run could not exercise.

• S6 could not exercise this: Uncaught connection refused error during protocol introspection. A net::ERR_CONNECTION_REFUSED console error is logged. The audit recorded the test environment as the cause, so it is not counted as an issue.
• S7 could not exercise this: Uncaught connection refused error during sidebar search. A net::ERR_CONNECTION_REFUSED console error is logged. The audit recorded the test environment as the cause, so it is not counted as an issue.
• S8 could not exercise this: Uncaught connection refused error on empty state search. A net::ERR_CONNECTION_REFUSED console error is logged. The audit recorded the test environment as the cause, so it is not counted as an issue.
• S9 could not exercise this: Uncaught connection refused error on opening Capabilities panel. A net::ERR_CONNECTION_REFUSED console error is logged. The audit recorded the test environment as the cause, so it is not counted as an issue.

The Critic reviewed 3 findings and ran 3 live replays in the browser, each on a fresh page.

• Scenarios S3, S4, and S5 stalled indefinitely on actions without recording console errors, while scenarios S6 through S9 recorded explicit ERR_CONNECTION_REFUSED errors.
• Hand correction, 2026-09-27: F1, F2 and F3 were all reproduced by hand in a real browser against api.rill.naisu.one. None hang indefinitely with zero feedback as originally worded, each fails after roughly 15 to 20 seconds with the same generic "Rill API didn't respond in time — try again" message. All three stay confirmed, the underlying backend unreliability is real, retitled to describe the actual behavior.

1. Make PTB flow simulation reliable and fast, and shorten the long stall before the "didn't respond in time" message (F1).
2. Make the publishing workflow reliable so action metadata registers and code export completes without a long stall or failure (F2).
3. Make protocol ABI introspection reliable and fast for a valid package, and shorten the current long stall before the "didn't respond in time" message (F3).

In scope: Sui Wallet connection on testnet; React Flow canvas loading and node templates; PTB dry-run simulation and gas estimations; MCP Server / TypeScript code export generation; On-chain ABI protocol introspection; Builder sidebar search and filtering.

Not covered: Actual on-chain PTB execution (simulation only, out of scope for testnet dry runs); Mainnet capabilities (wallet strictly locked to sui:testnet).

• The provided test wallet automatically approves connection requests without requiring a manual window switch
• The target package IDs for introspection tests are valid and published on Sui testnet
• Graph visual layout changes (auto-arrange) are observable in the DOM or canvas attributes