Update asset issuance tutorial to use RPC instead of Horizon

[kaankacar]

🤖 Automated triage bot, acting for @kaankacar.

Closes #1777

The asset issuance tutorial called Horizon in all four languages. This points every example at Stellar RPC. Account loads become getAccount, load_account, LoadAccount and getAccount. Submission becomes sendTransaction plus a poll, because RPC answers PENDING first. The page keeps its four languages, and no example needs an endpoint that RPC lacks.

[github-actions]

PR Preview: https://developers-pr-2833.previews.kube001.services.stellar-ops.com

[Copilot]

Pull request overview

Updates the “How to issue an asset” tutorial to use Stellar RPC (account reads + transaction submission + polling) instead of Horizon across all four language examples, aligning the page with the docs’ current RPC-first guidance.

Changes:

• Adds an RPC-specific explanation (send → PENDING → poll via getTransaction/pollTransaction).
• Migrates JavaScript/Python/Java/Go snippets from Horizon account loading/submission to RPC equivalents (getAccount / load_account / LoadAccount, sendTransaction + polling).
• Switches Go examples from horizonclient to rpcclient and updates transaction-building to use the loaded account objects.

Recommendation: NEEDS-CHANGES — the newly added submission helpers treat any non-PENDING status as a hard failure, but RPC can return other non-error statuses (e.g. DUPLICATE, TRY_AGAIN_LATER) that shouldn’t be rejected; additionally one JS snippet uses top-level await with CommonJS require() which won’t run if copied verbatim.

Suppressed comments (4)

docs/tokens/how-to-issue-an-asset.mdx:597

• send_transaction can return non-PENDING statuses that are not submission failures (e.g. DUPLICATE, TRY_AGAIN_LATER). Failing on anything except PENDING makes the example reject valid responses; consider only raising on ERROR and otherwise polling by hash.

    send_response = server.send_transaction(transaction)
    if send_response.status != SendTransactionStatus.PENDING:
        raise RuntimeError(f"Submission failed: {send_response.status}")

docs/tokens/how-to-issue-an-asset.mdx:689

• sendTransaction can return DUPLICATE or TRY_AGAIN_LATER in addition to PENDING; treating any non-PENDING status as a submission failure can reject valid responses. Consider only throwing on ERROR and otherwise polling by hash.

SendTransactionResponse trustSend = server.sendTransaction(allowAstroDollars);
if (trustSend.getStatus() != SendTransactionStatus.PENDING) {
  throw new RuntimeException("Submission failed: " + trustSend.getStatus());
}

docs/tokens/how-to-issue-an-asset.mdx:706

• sendTransaction can return DUPLICATE or TRY_AGAIN_LATER in addition to PENDING; treating any non-PENDING status as a submission failure can reject valid responses. Consider only throwing on ERROR and otherwise polling by hash.

SendTransactionResponse paymentSend = server.sendTransaction(sendAstroDollars);
if (paymentSend.getStatus() != SendTransactionStatus.PENDING) {
  throw new RuntimeException("Submission failed: " + paymentSend.getStatus());
}

docs/tokens/how-to-issue-an-asset.mdx:739

• SendTransaction can return statuses other than PENDING (e.g. DUPLICATE, TRY_AGAIN_LATER) that aren’t necessarily submission failures. Failing hard on any non-PENDING status can cause the example to reject valid responses; consider only treating ERROR as a submission failure and otherwise polling by hash.

  sendResp, err := client.SendTransaction(ctx, protocol.SendTransactionRequest{Transaction: txnB64})
  if err != nil {
    log.Fatal(err)
  }
  if sendResp.Status != "PENDING" {
    log.Fatalf("Submission failed: %s", sendResp.Status)
  }

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.