Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Auto-deploy MockKeystoneForwarder for experimental chains during simulation

Offen
  • Stimmt etwas nicht?
#393 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
52/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Ruhig
Tech-Stack
go
Bereich
blockchain, cli

Rechercherichtung

Beginne in cmd/workflow/simulate/simulate.go beim Fehler wegen des fehlenden Forwarders nahe Zeile 175 und untersuche anschließend test/MockKeystoneForwarder.json sowie den RPC-Ablauf der Simulation. Überprüfe, wie eth_getCode, CRE_ETH_PRIVATE_KEY und das Deployment gehandhabt werden. Als erledigt gilt, dass ein nicht angegebener Forwarder den Mock wiederverwendet oder deployt, seine Adresse protokolliert und das bestehende Verhalten beibehält, wenn einer angegeben ist.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Description

When using experimental-chains in project.yaml, users must manually deploy a MockKeystoneForwarder contract and provide its address in the forwarder field. This adds friction to the local development workflow, especially when using tools like Anvil for local testing.

Current behavior
experimental-chains:
  - chain-selector: 31337
    rpc-url: http://127.0.0.1:8545
    forwarder: "0x..."  # User must deploy and provide this manually

If the forwarder field is missing or incorrect, the simulation silently fails — the forwarder can't deliver reports to the receiver contract, and there's no clear error message indicating the issue.

Proposed behavior

When cre workflow simulate runs with an experimental chain that has no forwarder specified:

  1. Compute a deterministic address for the MockKeystoneForwarder
  2. Check if code already exists at that address (eth_getCode) — if found, reuse it
  3. If no code found, auto-deploy it using the private key from CRE_ETH_PRIVATE_KEY
  4. Use the deployed/existing address for the simulation
  5. Log the address so the user is aware

This avoids redeploying on every simulation run while keeping the forwarder field optional, matching the seamless experience of official chains where the simulator handles this automatically.

Context

While setting up CRE workflow simulation against a local Anvil instance, we initially deployed the KeystoneForwarder contract instead of the MockKeystoneForwarder. The simulation appeared to succeed (returned a tx hash), but the forwarder's report delivery silently failed. There was no error indicating we needed the mock version. It took significant debugging — tracing transactions, checking ERC165 interface IDs, and inspecting ReportProcessed events — to discover the issue.

Auto-deploying the correct MockKeystoneForwarder during simulation would eliminate this confusion entirely and save developers from a non-obvious debugging path.

###Proposed implementation
The change would be in cmd/workflow/simulate/simulate.go around line 175, where it currently errors on missing forwarder:

return Inputs{}, fmt.Errorf("experimental chain %d missing forwarder", ec.ChainSelector)

Instead of erroring:

  • Compute a deterministic address for the MockKeystoneForwarder (e.g., using CREATE2 or a fixed nonce)
  • Call eth_getCode at that address — if bytecode exists, reuse it without redeploying
  • If no code found, deploy using the user's private key from CRE_ETH_PRIVATE_KEY
  • Log: "No forwarder specified for experimental chain %d — using MockKeystoneForwarder at %s"

The compiled artifact already exists in the repo at test/MockKeystoneForwarder.json. If forwarder is provided, behavior remains unchanged.

Happy to submit a PR if the team is open to this approach.

Vorherrschende Sprache
Go
Sterne
24
Forks
29
Ø Merge
1 T. 1 Std.
Gemergte PRs (30 T.)
8

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus smartcontractkit/cre-cli

Alle Issues in smartcontractkit/cre-cli

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.