use source of truth contract to derive addresses #3
Conversation
parkan
commented
Feb 2, 2026
parkan
commented
- reads from primary contract to derive addresses
- CI test to bail on mismatch
- more in-depth integration test (manual only right now)
| echo "run 'go generate ./constants/...' and commit the result" | ||
| echo "" | ||
| echo "if using old addresses intentionally, add [skip-address-verify] to commit message" | ||
| exit 1 |
There was a problem hiding this comment.
The generator and CI job will fail if the Glif RPC endpoints are unavailable during go generate. This could block CI for unrelated PRs if there's an RPC outage.
A few options to consider:
- Add retry logic with backoff in the generator
- Cache the last known good
addresses_generated.goand only fail CI if addresses actually changed (vs just failing to fetch) - Mark the
verify-addressesjob ascontinue-on-error: truewith a warning instead of failure on network errors
Not blocking, but worth considering for resilience.
There was a problem hiding this comment.
good point, I will make it continue if glif is down, it seems like the importance of this mechanism is still somewhat under debate upstream so I'm not going to overindex on it
| fmt.Printf(" spregistry: %s\n", mainnet.SPRegistry.Hex()) | ||
| fmt.Printf(" sessionkey: %s\n", mainnet.SessionKeyRegistry.Hex()) | ||
|
|
||
| fmt.Println("reading calibration addresses...") |
There was a problem hiding this comment.
The 30-second timeout applies to the entire operation across both networks. If one RPC is slow, it could leave insufficient time for the second.
Consider either:
- Using separate timeouts per network (e.g., 30s each)
- Increasing the overall timeout to 60s to give more headroom
Minor concern - current timeout is probably fine under normal conditions.
|
other than the inlined comments lgtm (famous last words) |
2 participants
